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CHAPTER  1 
Introduction 


1.1.  Summary 


This  thesis  discusses  the  application  of  LCF  (Logic  for  Computable 
Functions)  to  the  problem  "Given  a programming  language,  define  precisely  the 
semantics  and  develop  a mathematical  theory  which  is  suitable  for  reasoning  about 
programs  of  the  language".  It  is  primarily  concerned  with  building  an  axiomatic 
theory  of  Pure  LISP  which  can  be  used  in  the  extraction  of  meanings  of  LISP 
functions.  Particular  functions  discussed,  in  terms  of  correctness,  are  ones  which 
perform  interpretation  and  compilation  of  subsets  of  LISP.  A principal  aim  of  the 
investigation  was  an  evaluation  of  both  the  expressive  and  the  deductive  power  of 
LCF. 


1.2.  History  of  the  'LCF  Project’ 


The  starting  point  was  an  underground  paper  by  Dana  Scott  [1]  in  1969 
describing  a typed  combinatory  logic  which  was  suitable  for  recursive  function 


li 


theory.  Robin  Milner,  in  1971,  replaced  the  combinators  with  typed  lambda  calculus 
and  that  logic  will  be  referred  to  as  Pure  LCF.  He  also  implemented  a proof  checker 
for  this  version  of  the  logic  and  this  program  (later  improved  upon)  is  called  the  LCF 
System,  or  simply  LCF.  Milner  described  Pure  LCF  and  the  LCF  System  in  [2] 
(including  come  examples  of  the  use  of  the  program),  [3]  is  a user’s  manual  for  the 
system  and  [4]  contains  the  only  available  technical  discussion  of  the  model  theory 
of  the  logic.  For  the  sake  of  self-containment,  a short  tutorial  on  Pure  LCF  is 
included  in  this,  npparl  as  Chapter  2 end  because  improvements  to  the  LCF  System 
are  a major  concern  of  this  study,  Chapter  3 is  a brief  description  of  the  LCF 
System  as  it  now  exists  (in  fact  an  improvement  on  the  version  described  in  [3]). 

Milner  caw  LCF  as  an  excellent  tool  for  the  Mathematical  Theory  of 
Computation  ( MTC  ) and  it  is  in  this  capacity  that  LCF  has  attracted  some  attention 
(within  the  field  of  computer  science).  The  first  chapters  in  the  application  of  this 
tool  to  MTC  problems  were  written  by  Milner  and  Weyhrauch  (1972)  with  two 
documented  experiments  involving  proofs  of  program  properties.  [5]  discusses  the 
proof  of  the  correctness  and  termination  of  a simple  program  (for  the  factorial 
function)  in  a simple  algebraic  language  defined  by  means  of  its  abstract  syntax.  [6] 
reports  on  the  development  in  the  LCF  System  of  a proof  of  the  correctness  of  a 
simple  compiling  algorithm.  That  algorithm  dealt  with  the  abstract  analytic  syntax  of 
the  source  language  which  featured  the  constructs  of  arithmetic  expression  (with 
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binary  operator  * and  variables)  with  assignment,  conditional,  compound  and  'while’ 


statements.  The  target  language  was  for  a machine  with  an  accumulator,  a memory 
anj  a stack;  it  contained  conditional  arid  absolute  jumps,  toad  and  fetch  commands, 


labels  and  an  instruction  to  apply  arbitrary  binary  operators.  Much  of  this 


experiment  was  concerned  with  the  application  of  algebraic  techniques  to  give 


structure  to  the  proof. 


Although  the  proofs  in  the  Weyhrauch-Milner  experiments  were  machine 


checked,  it  was  expedient  to  assume  many  theorems  from  areas  such  as  arithmetic 


and  finite  set  theory  rather  than  prove  them  in  axiomatically  based  subtheories. 


The  results  in  question  were  all  considered  'intuitively  obvious’  but  the  practice 


allows  errors  to  creep  in.  What  was  needed  for  succeeding  experiments  was  a 


mathematical  environment  based  on  axiomatic  treatments  of  the  usual 


background  areas  such  as  arithmetic.  A step  in  this  direction  was  taken  by  Newey 


[7]  who  gave  suitable  developments  of  a basic  propositional  logic,  natural  numbers, 


arithmetic  over  the  integers,  lists  and  finite  sets.  The  library  of  results  obtained  in 


that  venture  amounted  to  some  1000  theorems  and  was  more  comprehensive  than 


our  present  needs  require.  We  give,  therefore,  Chapter  4 as  summary  of  of  the 


parts  of  [7]  that  are  relevant  to  giving  the  semantics  cf  LISP. 


Viewed  in  the  light  of  this  history,  the  formalisation  of  LISP  semantics  (in 


LCF)  appears  as  another  step  in  the  application  of  LCF  to  the  problems  of  MTC.  In 


l 


l 


fact  one  of  the  main  concerns  in  the  experimental  work  is  that  it  should  inspire 
criticism  of  the  current  LCF  system  that  can  be  translated  into  improvements  to  be 
realized  in  the  next  version. 


1.3.  Past  Work  in  Formal  Semantics 

A survey  on  semantics  of  programming  languages  was  given  by  J.W.  de 
Bakker  in  [18].  Although  it  is  getting  old,  we  shall  simply  update  it  with  pointers  in 
the  bibliography  to  more  recent  work  by  Burstall,  Gordon,  Hoare,  Lauer,  Manna, 
WalcJinger  and  the  Oxford  school  as  well  as  the  Milner-Weyhrauch  work  cited  above 
Of  particular  relevance  is  a short  survey  in  [6]  on  compiler  correctness. 

There  have  not  yet  been  any  critical  comparisons  with  previous  formalisms 
but  certain  properties  of  LCF  must  be  conceded  to  be  big  advantages.  First  it  is 
based  in  logic  and  so  it  has  deductive  as  well  as  expressive  power  (i.e.  we  can  use 
it  to  reason  about  programs  as  well  as  define  the  semantics  of  languages).  Second, 
it  deals  with  functions  (possibly  partial)  and  functionals  conveniently  because  of  the 
lambda  calculus  base.  Last,  there  are  very  good  chances  that  automatic  deduction 
will  be  moderately  successful. 

In  terms  of  foundations  for  the  present  work,  we  follow  the  constructive 
approach  that  McCarthy  has  used  but  do  it  axiomatically  in  a logic  as  Burstall 
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proposed  When  we  develop  mathematical  theories  of  a language  we  get  theorems 
about  the  local  effect  of  language  features  that  rather  resemble  Hoare’s  rules.  We 
also  depend  heavily  on  McCarthy’s  notion  of  abstract  syntax  as  presented  in  [25] 
and  [261 

Chapter  5 shows  how  we  are  able  to  factor  syntax  and  semantics  for  LISP. 
The  technique  makes  use  of  abstract  syntax  and  functions  for  mapping  between 
concrete  text  and  abstract  representations  of  programs  and  data.  That  chapter 
discusses  the  concepts  of  ’notation’  and  ’denotation’  in  relation  to  LISP. 

1.4.  A Treatment  of  Pure  LISP 

McCarthy  presented  Pure  LISP  in  [15]  but  we  take  [12]  to  be  the 
authorative  reference  since  it  is  later  (1962)  and  a touch  smoother.  Following  his 
example  we  specify  the  language  by  means  of  an  'interpretive  semantics’  which  uses 
association  lists  to  bind  values  to  variables.  More  precisely,  taking  both  LISP  data 
and  functions  to  be  S-expressions  over  a suitable  set  of  names,  a function  is  defined 
in  LCF  in  such  a way  that  it  interprets  source  LISP  expressions  appropriately. 
Moreover,  that  function  makes  use  of  'eval’  and  ’apply’  functions  which  behave  as 
the  McCarthy  Pure  LISP  functions  of  the  same  names.  The  LCF  definitions  of  these 
functions  together  with  the  axioms  which  specify  the  notions  of  ’name’  and 


S-expression’  form  a baois  for  a mathematical  theory  of  Pure  LISP.  Chapter  6 
presents  the  axioms  and  describes  a rudimentary  theory  (a  body  of  theorems)  which 
will  greatly  ease  the  task  of  proving  things  about  Pure  LISP  functions. 

This  semantics  for  theory)  was  then  used  to  prove  that  certain  sample  Pure 
LISP  expressions  denote  the  appropriate  mappings  on  S-expressions.  The  particular 
functions  were  NULL,  EQUAL  and  ASSOC.  Chapter  7 discusses  the  proofs  which 
were  generated  and  checked  using  the  LCF  system  since  they  illustrate  some 
general  techniques. 

The  examples  culminate  in  a discussion  of  the  correctness  of  the  S- 
expression  version  of  McCarthy’s  interpreter  for  Pure  LISP  which  is  written  in  Pure 
LISP  itself.  Actually,  we  will  seek  to  establish  the  correctness  of  the  S-expression 
form  of  'eval'  which  we  will  cal!  Seval.  The  property  we  want  to  prove  is  "For  any 
A-list  al,  the  function  denoted  by  Seval  via  interpretation  is  'eval’  itself", 
i.e.  Ve  a.  applyf Seval, (e  a),al)  s eval(e,a) 

Chapter  8 addresses  this  problem  and  presents  lemmas  (proved  with 
assistance  of  the  LCF  system)  which  show,  in  particular,  that  the  functions  'eval’  and 
[xe  a.  apply(Seval,(e  a),al)]  satisfy  almost  identical  recursive  equations.  These 
lemmas  enable  us  to  conclude  in  the  metatheory  of  LCF  that  the  functions  are 
indeed  the  same.  Reasoning  within  the  logic  it  was  possible  to  prove  a sort  of  weak 
correctness: 

6 


•?i  ^ aBafi^awwiMaiwgwMft^IpwipfH^^ 

* '*  ikiu 


1 


I 


m 


>: 

*1''' 


m 


i f 


i 


Ve  a.  eval(e.a)  £ apply(Seval,(e  a),al) 


but  the  attempts  to  prove  the  other  half  of  the  above  equality  led  to  an 
identification  of  a deficiency  in  the  LCF  system.  More  specifically  the  other  part  of 
the  proof  would  have  required  more  space  and  time  for  computation  than  feasible. 


1.5.  Correctness  of  a Compiler 


London  in  [13]  gave  a rather  informal  proof  of  the  correctness  of  a certain 
compiler  for  a subset  of  LISP;  LAP  (a  variety  of  PDP10  machine  code)  was  the 
target  language.  This  compiler,  which  is  called  LComO,  was  written  by  McCarthy  as 
a pedagogic  device  for  a course  at  Stanford.  Also,  as  mentioned  before,  Milner  and 
Weyhrauch  gave  a formal  proof  of  a minimal  compiling  algorithm  using  LCF.  It  was 
therefore  clear  that  LCF  was  an  appropriate  vehicle  for  attempting  the  rigorous 
verification  of  compilers  like  LComO. 

Two  chapters  are  devoted  to  a detailed  study  of  the  feasibility  of 
establishing  the  correctness  of  LComO  within  the  LCF  system.  The  total  task  factors 
evenly  to  four  subproblems.  The  first  two  are  the  axiomatisations  of  the  two 
languages  involved.  The  third  is  the  extraction,  from  the  S-expression  version  of 
the  compiler,  of  its  meaning  function  - 'the  compiling  algorithm’.  The  last  is  the 
establishment  of  the  correctness  of  this  compiling  algorithm. 
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The  treatment  of  the  LISP  subset  parallels  the  work  on  Pure  LISP  in  that 
axioms  defining  the  language  are  expanded  into  a usable  theory  for  the  language  by 
deriving  theorems. 

The  meanings  of  those  instructions  that  are  generated  by  LComO  are  given 
in  an  abstract  formalism  which  interprets  the  action  of  assembly  code  programs  on 
machine  state*  Tfc*  tcwfetfcro  is  an  abstraction  in  that  no  account  is  taken  of  store 
size,  word  size,  the  actual  representation  of  S-expressions  or  garbage  collection.  As 
in  the  case  of  Pure  LISP,  certain  handy  lemmas  are  proved  and  described.  This 
material  takes  us  through  Chapter  9. 

Chapter  10  starts  with  the  discussion  of  the  extraction  of  the  compiling 
algorithm  from  the  S-expressions  for  LComO.  The  same  techniques  illustrated  in 

Chapter  7 are  used  although  the  larger  S-expressions  lead  to  correspondingly  longer 
proofs. 

The  normal  use  of  the  compiler  is  to  translate  a 'program’  of  LISP  functions 
into  a program  of  LAP  functions.  We  then  say  that  a statement  of  compiler 
correctness  is  in  all  such  situations  the  the  answer  obtained  by  executing  any  LAP 

function  must  agree  with  the  result  of  calling  the  corresponding  LISP  function  with 
the  same  arguments". 

Whereas  our  study  of  the  other  parts  of  the  problem  showed  that  attacks 
using  LCF  are  quite  feasible  with  the  current  LCF  system,  the  proof  of  correctness 


8 


‘ A in  ( ii  Liiitl  l'M  » i'ioiir 


30 

3#? 


o 


ST 

I >- 


i 


I 


x. 


f!  o 


of  the  compiling  algorithm  is  much  too  long.  In  retrospect,  this  is  not  surprising  since 
the  compiler  is  an  order  of  magnitude  larger  than  the  one  Milner  and  Weyhrauch 
worked  with  and  the  languages  are  also  more  complicated. 

Although  the  proof  was  not  carried  out  we  do  discuss  its  structure  and 
suggest  in  which  directions  the  deductive  power  of  the  LCF  system  must  be 
improved  before  the  proof  becomes  feasible. 


1.6.  Second  Generation  LCF 


Chapter  1 1 presents  suggestions  for  the  design  of  a new  LCF  system.  The 
main  design  change  is  that  the  system  should  be  two  separate  programs  - a simple 
proof  checker  for  a restricted  form  of  LCF  and  an  interactive  proof  generating 
program.  There  are  also  suggestions  for  making  the  input  language  to  the  system 
more  ’high  level’.  A mechanism  is  presented  for  having  a resticted  class  of  derived 
deduction  rules  provable  within  LCF.  Some  attention  is  given  to  further  extensions 
of  simplification  ana  some  suggestions  for  new  deduction  mechanisms  are  examined. 


1.7.  The  Problem  of  Side-Effects 


Both  subsets  of  LISP  mentioned  above  contain  just  a few  of  the  interesting 
features  of  practical’  varieties  of  LISP.  The  most  notable  missing  features  are 
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SETQrs  and  PROG's.  The  second  appendix  gives  another  LCF  interpretive  semantics 
v/hich  can  handle  certain  side-effect  features  of  LISP  - SETQs  and  the  regular 
GEfcCYM  device.  It  also  deals  with  the  PROG  construct  but  still  does  not  handle 
arrays  or  property  lists  and  certainly  not  the  distinction  between  the  LISP  1.5 
functions  EQ  and  EQUAL  Again  we  cleat  with  an  idealisation  of  LISP  which  is  not 
subject  to  recursion  depth  limits,  finite  arithmetic  or  boundeo  memory  capacity. 
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CHAPTER  2 
Pure  LCF 


In  this  short  exposition  of  Scott’s  logic  no  justification  of  the  semantics  is 
given;  the  curious  reader  should  consult  [4]. 


2.1.  Terms,  Types  and  Domains: 


2.1.1.  Syntax 

The  terms  of  LCF  are  those  cf  a typed  \-calculus  with  the  addition  of  a 
least  fixed  point  operator  and  certain  constants;  the  two  base  types  are  called  'tr’ 
(for  truth  values)  and  ’ind’  (for  individuals).  All  types  other  than  'tr*  or  'ind’  are 
derived  from  these  two  by  a finite  number  of  applications  of  the  rule  "If  « and  fl 
denote  types  then  so  does  With  every  term  of  the  logic  there  is  an 

associated  type  and  we  may  postfix  terms  with  their  types  so  that,  for  example, 
t:/?  indicates  that  term  t has  type  The  syntax  of  LCF  terms  is  then  given  by  the 
productions: 


<term:/?>  = <identifier:/?>  | <application:/?>  J 

<conditianal:/tf>  | <x-exprn:/?>  | <ji-exprn:/3> 


where  <application:/?2>  = <term:(/*l->/?2)>  ( <term:/?l>  ) 
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•'conditional:/?:*  = <term:tr>  - *:term:/?>  , <term:/?> 

<\-exprn:(/?l-*/?2)>  = [\  <identifier:/?l>  . <term:/?2>  ] 

<M-exprn:/?>  = [n  <identifier:/?>  . <term:/?>  ] 
and  where  identifiers  are  defined  in  the  usual  way. 

2.1.2.  Semantics 

Terms  of  type  /?  denote  objects  in  a domain  which  is  to  be  a partially 
ordered  set  (ordering  relation  s ) with  every  ascending  chain  having  a least  upper 
bound  in  D/t.  Moreover,  each  D/3  contains  a minimum  element  denoted  by  the  logical 

0 

constant  1^;  that  is,  l/s  s x for  all  x < D/3. 

The  interpretation  intended  for  the  relation  's’  in  the  various  domains  is 
that  of  relative  definedness.  That  is,  xsy  is  to  be  interpreted  as  saying  y is  at  least 
as  defined  as  (and  consistent  with)  x.  Hence  we  see  that  for  a domain  the 
interpretation  of  JL is  that  of  the  completely  undefined  element. 

The  base  domain  D,r  (the  domain  of  truth  values)  contains  precisely  three  0 

elements  ( ltr,  T,  F ) in  the  fixed  order  given  by  the  diagram: 
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The  other  base  domain  D,nd  (the  domain  of  individuals)  is  normally 
constrained  by  the  addition  of  some  non-logical  axioms  to  characterise  the  non- 
functional data  in  a universe  of  discourse. 

Finally,  D(<.._/S)  is  the  domain  of  continuous  functions  from  D*  to  D^.  A 
continuous  function  is  one  which  preserves  the  least  upper  bounds  of  ascending 
chains.  However,  we  shall  never  be  using  this  notion  explicitly  so  simp.y  take  it  as 
fact  that  functions  and  functionals  formed  by  all  the  term  constructing  mechanisms 
(presented  above)  are  continuous.  A property  of  these  functions  is  that  they  are 
monotonicj  i.e.,  if  F is  in  D(&wj)  and  x:«  e y:c<  then  F(x)  e F(y). 

The  interpretations  of  application  and  x-abstraction  are  the  usual  ones. 
The  term  S:tr  -»  Tl:/<,  T2:/i  denotes  ifi  or  one  of  the  two  objects  in  denoted  by 
T1  and  T2,  according  to  whether  S denotes  llr,  T or  F respectively. 

[Mf.S]  should  be  interpreted  as  denoting  the  minimal  fixed  point  of  the 
function  [xf.S].  G is  a fixed  point  of  |>f.g(f)]  if  G denotes  the  same  function  as  g(G); 
minimality  is  taken  with  respect  to  ‘e’  . 


2.1.3.  Strictness  and  Discreteness 

A function  F(^fi)  is  termed  strict  if  the  value  of  F(lJ  is  A domain 

D,v  is  termed  discrete  or  flat  if  for  any  x„.  and  y*,  x*  - v,  implies  x^sy^  or 
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2.1.4.  An  Example 

To  illustrate  these  notions  let  us  construct  the  factorial  function  in  terms  of 
arithmetic  primitives.  We  imagine  that  we  are  given  non-logical  axioms  which 
constrain  the  domain  of  individuals  to  contain  a structure  which  looks  like  the  natural 
numbers.  So  D,nd  contains  an  individual  which  we  call  0 and  there  is  a successor 
function  which  generates  all  natural  numbers  by  repeated  application  to  0 (1  is  the 
successor  of  0).  We  suppose  Z is  a predicate  which  is  T on  0 and  F on  all  other 
natural  numbers.  It  is  an  easy  exercise  to  use  monotonicity  to  show  Z(l)  must  be  1. 
(Note  we  are  beginning  to  omit  the  mention  of  types  when  the  information  can  be 
recovered  from  context.)  We  also  make  use  of  a predecessor  function  'pred’  and  a 
two  argument  multiply  function  V. 

l>F.|>x.  Z(x)  -*  1,  *(x)(F(pred(x»)]] , which  we  call  'fact’,  is  an  example  of 
a term  and  contains  instances  of  application,  conditional  expression,  \-abstraction 
and  the  minimal  fixed  point  operation.  It  also  involves  bound  variables  (*x’  and  'F’). 
This  term  denotes  the  least  defined  function  which  satisfies  the  recursive  definition 

F(x)  <$*  if  x=0  then  1 else  x#F(x-l)  . 

The  types  of  the  various  atoms  are  as  follows:-  'O’,  T and  'x’  all  have  type 
ind;  T has  type  (ind-tr);  'pred’  and  T have  type  (ind-nnd);  V’  has  type 
(ind-(ind-ind)).  To  illustrate  why  we  are  interested  in  least  fixed  points  of 
functions  note  that  the  above  recursive  definition  is  satisfied  by  another  function 
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'fact 2*  which  agrees  with  'fact'  but  gives  zero  on  all  negative  numbers  (assuming 
these  are  also  in  D,nd).  It  will  be  provable  that  fact  e fact2  . 

2.2.  Formulae,  Sentences  and  Proofs! 

An  Atomic  Well  Formed  Formula  ( AWFF  ) has  (for  arbitrary 
type  [\  ) the  form  <term:/?>  e <term:/?>  . The  symbol  's’  is  of  course  identified 
with  the  ordering  relation  on  and  so  the  interpretation  of  AWFFs  is  obvious. 

A Well  Formed  Formula  (WFF)  is  a set  of  (zero  or  more)  AWFFs. 
WFFs  are  written  as  lists  using  comma  as  a separator.  It  follows  from  this  definition 
that  "aEb,  ced"  is  the  same  WFF  as  "csd,  asb,  asb”  . A WFF  is  intended  to  denote 
the  conjunction  of  its  constituent  AWFFs.  Hence,  the  comma  should  be  also 
interpreted  as  conjunction.  We  abbreviate  "sst,  tEs"  as  "sst" . 

An  LCF  sentence  has  the  form  P }-  Q where  P and  Q are  WFFs.  The 
'turnstile’  symbol  should  be  interpreted  as  implication.  If  P is  empty  we  omit  it 
entirely. 

Finally,  a proof  is  a sequence  of  sentences  with  the  property  that  each  is 
either  an  instance  of  an  axiom  schema  of  Pure  LCF  or  a deduction  from  previous 
sentences  in  the  sequence  using  a rule  of  inference. 


Cases  Rule 


P,s=T  h Q P jSeX  H Q P,s*F  h Q 


P h Q 

Induction  Rule  P H Q{l/x)  PtQ  H Q{t/x} 

P h Q{[MX.t]/x}  (x  not  free  in  P) 

2.4.  Some  Examples: 

2.4.1.  A-B,  BnC  H A=C  . 

In  this  proof  of  an  instance  of  the  transitivity  of  's’,  note  that  the  rules  of 
Pure  LCF  are  quite  low  level.  The  actual  'proof’  is  just  the  centre  column  of 
sentences  and  the  justifications  are  for  the  benefit  of  the  reader. 


(a) 

A-B  h AeB 

by  Inclusion  Axiom; 

(b) 

B=C  f-  BeC 

by  Inclusion  Axiom; 

(c) 

A=B,  B=C  f-  AeB,  BeC 

by  Conjunction, (a), (b); 

(d) 

AeB,  BeC  f-  AeC 

by  Transitivity  Axiom; 

(e) 

A=B,  B=C  h AeC 

by  Cut,(c),(d); 

(f) 

AsB  H BeA 

by  Inclusion  Axiom; 

(g) 

b-c  H CeB 

by  Inclusion  Axiom; 

(h) 

A~B,  B-C  h CeB,  BeA 

by  Conjunction, (g),(f); 

<j) 

CeB,  BeA  h CeA 

by  Transitivity  Axiom; 

(k) 

A---B,  B*C  h CeA 

by  Cut,(h),(j); 

(1) 

A-B,  B-C  h A=C 

by  Conjunction, (e),(k); 
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2.4.2.  FrG,  AcB  h RA)^G(B)  . 

Although  this  example  Is  a trivial  theorem  of  monotonicity  it  can  be  applied 
iteratively  to  get  more  complex  theorems.  Again  the  proof  is  quite  tedious: 

(a)  AsB  }-  F(A)cRB)  by  Application  Axiom; 

(b)  F^G  H [xf.f(B)]<F)s[xf.f(B)](G)  by  Application  Axiom; 

<c>  H [xf.f(B)](F)sF(B)  by  a Conversion  Axiom; 

(d)  [x f.f(B)](F)  -F(B)  H F<B> s[xf.f(B)](F)  by  Inclusion  Axiom; 

(e)  h F(B)?[xf.f(B)](F)  by  Cut,(c),(d>; 

(0  F?G  h F{B> s[xf.f(B>]<F),  [xf.f(B)](F) s[xf.f(B)](G> 

by  Conjunction, (e),(b); 

(g)  F(B)s[xf.f(B)]<F),  [xf.KB)](F)e[xf.f(B)](G)  b F(B) s[xf.f(B> ](G> 

by  Transitivity  Axiom; 

<h>  F-G  b F<B)s[xf.f(B>]<G)  by  Cut,(f),(g); 

<j)  H [xf.f(B)j(G)“G(B)  by  a Conversion  Axiom; 

(k)  [xf.f(B)](G)-G(B)  }■  [xf.f<B)](G> eG(B>  bv  Inclusion  Axiom; 

(l)  b [xf.f(B)](G)sG<B)  by  Cut,<j),(k); 

(m)  F-G  \-  F(B) s[xf.f( B>](G>,  [xf.f(B)](G) sG(B) 

Conjunction,  (h),(l); 

<n)  F(B)s[xf.f(B)](G>,  [x f . f < B) ]( G> e G( B>  |-  F(B>sG(B) 

by  Transitivity  Axiom; 

(p)  FsG  b F(B)sG(B)  by  Cut,(m),(n); 


A9B,  F-G  b F< A) sF<B>,  F(B)eG(B) 
RA)<eRB),  F(B)sGfB)  b RA)eG(B) 
AsB,  FeG  b RA)sG(B) 


by  Conjunction, ( a), (p); 
by  Transitivity  Axiom; 
by  Cut,(q),(r); 
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CHAPTER  3 

The  LCF  Proof  Checking  System 


In  this  section  we  describe  the  computer  program  which  aids  in  the 
generation  of  validated  proofs  in  an  enhanced  version  ©t  LCF.  Both  the  program  and 
the  enhanced  logic  are  called  simply  "LCF"  and  ambiguities  will  be  resolved  by 
context.  When  we  refer  to  the  logic  of  Chapter  2 we  shall  always  refer  to  U ae 
Pure  LCF. 


3.1.  Proofs: 


A Pure  LCF  proof  is  a sequence  of  sentences  subject  to  the  condition  that 
each  of  the  sentences  is  an  instance  of  one  of  the  logical  axiom  schemas  of  Pure 
LCF  or  follows  from  previous  sentences  (in  the  sequence)  by  a rule  of  inference.  A 
proof  in  the  LCF  implementation  is  a sequence  of  'steps’  and  a step  is  a four 
element  list  (n,  W,  D,  J)  where  n is  the  step-number  (an  integer),  W is  an  LCF 
WFF,  D is  a list  of  the  dependencies  of  the  step  and  J is  the  justification.  Steps 
are  numbered  sequentially  as  they  are  generated  and  added  to  the  end  of  the 
partial  proof.  The  dependencies  of  a step  are  the  step  numbers  of  'assumptions’ 
on  which  the  current  step  depends.  The  justification  of  a step  indicates  how 
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the  step  was  generated;  it  will  include  the  name  of  the  rule  of  inference  employed 
and  the  previous  steps  that  were  used. 

An  assumption  is  a special  step  of  the  form  (n,  W,  (n),  (ASSUME  W)). 
Note  that  the  only  dependency  of  an  assumption  is  itself.  Another  special  type  of 
step  is  an  axiom  which  has  the  form  (n,  W,  (>,  (AXIOM  A))  where  A is  the  axiom 
name;  note  that  axioms  have  no  dependecies, 

Wc  now  define  the  sentence  denoted  by  a step  (n,  W,  (d|,d2,...dm),  J)  to 
be  Wd|,  Wd? Wdm  H W where  Wd|  is  the  WFF  part  of  the  line  d,  (which  will  be 

an  assumption).  Thus,  the  step  (n,  W,  (),  (AXIOM  A))  denotes  the  sentence 
b W and  the  sentence  denoted  by  the  step  (n,  W,  (n),  (ASSUME  W))  is 
clearly  W H W . 


3.2.  Formulae  and  Terms! 


Not  only  do  we  have  somewhat  different  notions  of  'proof’  in  the  pure  logic 
and  in  implemented  LCF  (albeit  there  is  a correspondence  between  them),  but  there 
are  slight  changes  to  the  meanings  of  WFFs  and  terms. 

First  of  all  is  not  regarded  as  simply  an  abbreviation,  but  has  a similar 
status  to  V.  Thus,  s=t  is  regarded  as  an  AWFF  (as  opposed  to  a WFF  in  Pure  LCF) 
and  there  are  deduction  rules  which  deal  with  these  'equalities’  (so  called)  rather 
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than  'inequalities’.  This  change  in  approach  is  justifiable  via  the  observation  that 


is  the  much  commoner  relation  and  much  easier  to  reason  with.  On  the  other  hand, 
extra  deduction  rules  are  necessitated  for  conversion  among  the  formulae  s*t  , 

( set,  Its  ) and  lss  . The  rules  provided  in  the  implementation  are 


HALF  $=t 


SYM  s^t 


EQUIV  set, Us 


It  should  be  noted  that  experience  has  (so  far)  indicated  that  these  rules 


are  rarely  invoked  (due  in  large  measure  to  the  rarity  of  the  V relation). 


Next,  also  contrary  to  the  definitions  in  Chapter  2,  the  WFFs  are  often 


regarded  by  the  program  more  as  lists  than  as  sets.  For  example,  s^t  is  not  the 


same  WFF  as  s=t,s«t  . This  is  necessary  to  some  extent  since  it  is  convenient  to  be 


able  to  talk  about  the  n-th  AWFF  of  a WFF  but  there  is  also  come  ugliness  about 


the  implementation  in  this  respect. 


In  the  current  implementation  there  is  no  provision  for  talking  about  type 


information.  (Henci  there  can  be  no  type  checking.) 


Finally  there  are  some  very  important  abbreviations  which  are  used  by  the 


program  to  make  proofs  more  readable.  These  apply  to  both  terms  and  AWFFS. 


The  following  relate  to  terms; 


[xa  b.  t]  abbreviates  [xa.  [xb.  t]], 


[xa  b c.  tj  abbreviates  [xa.  [xb.  [xc.  t]]]  etc. 


Kttl&  »..w 


ii) 


s(tl,t2)  abbreviates  s<tl)(t2), 
s(tl,t2,t3)  abbreviates  s<tl)(t2)(t3)  etc. 


. ; 


iii) 


if  F is  a function  which  normally  takes  2 arguments  then  we 
may  declare  it  infix  and  then  we  write  s F t for  F($,t). 


The  following  relate  to  AWFFS: 

i)  Vx.  s 9 t abbreviates  [xx.s]  e [\x.t]  and 

Vx.  s = t abbreviates  [xx.s]  = [xx.t] ; 

l 

The  notation  so  introduced  is  very  suggestive  of  its  normal 
application:  if  we  have  Vx.  s(x)-t(x)  then  for  all  terms  x 
we  can  deduce  s(x)=t{x). 


ii) 


R*  s s t abbreviates  R-»s,l  s R-»t,l  and 
R=>  s s t abbreviates  R->s,l  « R-*t,l ; 

The  structure  abbreviated  is  an  instance  of  a rather  common 
device  for  relativising  AWFFS.  Noting  that  the  sentence, 

W H R*  set 

is  equivalent  to  the  other  sentence, 

W,  R=T  F sst, 

we  see  that  the  V connective  corresponds  to  material 
implication. 
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3.3.  Using  the  LCP  System! 


The  LCF  Implementation  has  really  outgrown  the  name  of  'proof  checker*. 
Apart  from  the  fact  that  a user  rarely  types  a WFF  (the  information  he  gives  is 
generally  a sequence  of  commands  that  tell  the  machine  HOW  to  generate  the 
required  sequence  of  steps),  there  are  various  mechanisms  to  help  him  interactively 
prove  theorems  in  LCF.  On  the  other  hand,  one  couldn’t  be  so  bold  to  call  it  even 
an  ’interactive’  theorem  prover,  although  this  is  a direction  of  future  developments. 

One  of  the  most  important  aids  to  proof  generation  is  the  machinery  that 
allows  (even  encourages)  goal  directed  proving.  A user  may  state  target  steps  and 
att?;k  them  by  indicating  one  of  many  tactics  whereupon  the  program  deduces 
appropriate  subgoals  and  perhaps  some  relevant  assumptions.  Most  of  the  tactics 
are  the  inverses  of  rules  of  inference  since  appropriate  subgoals  are  ones  which,  if 
achieved,  lead  to  the  establishment  of  the  goal  by  some  rule  of  inference. 

The  inference  rules  of  Pure  LCF  are  rather  basic  and,  in  applications  to 
MTC,  too  low  level  to  be  workable.  However,  the  LCF  system  has  five  very 
important  derived  deduction  mechanisms:  substitution,  contradiction,  theorem  use, 
simplification  and  prefix  stripping. 
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3.3.1.  Substitution: 

Substitution  is  the  implementation  of  three  derived  deduction  rules  of  Pure 
LCF.  The  first  two  rules  (following  only  from  the  CONV  and  ABSTR  rules)  are: 


P |-  tl  st2 


P I-  tl^t2 


P H s-s{t2/t  1} 


P H sas{t2/tl} 


and  the  third  follows  from  these  together  with  the  TRANS  rule  (expanded  to  include 
the  *n’  relation,  of  course): 


P I"  tl»t2  , Q h W 


P.Q  h W{t2/tl 


There  are  the  usual  cautions  about  capture  of  bound  variables. 


3.3.2.  Contradictions: 

There  is  an  inference  rule  which  enables  proofs  by  contradiction.  We  take 
it  that  the  logic  is  consistent  and  so  assuming  that  one’s  non-logical  axioms  are  too, 
one  can  never  prove  sentences  such  as  |-  TsF  . Hence,  given  a step  containing  a 
■contradictory’  WFF  ( such  as  ' T-i  ’),  we  should  conclude  that  the  dependencies 
are  inconsistent.  Now,  given  such  a step  with  a ’contradictory’  WFF  (and 
dependencies  D;  in  an  LCF  proof  we  could  proceed  to  prove  any  other  WFF  with 
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the  same  dependencies  ( D ).  (It  is  a nice  exercise  to  show  this.)  The  program 
recognizes  the  following  four  inequalities  in  Dti,  as  contradictions: 

Tsi  Fa  TeF  f e T 


as  well  as  the  six  equalities  between  distinct  members  of  Dtr  (such  as  TsF)  and 
allows  the  user  to  prove  any  goal  (i.e.  make  it  a step)  by  claiming  it  follows  from  a 
contradiction.  The  resulting  step  win  have  the  dependencies  of  the  contradiction. 


3.3.3.  Theorems: 

In  the  pure  logic,  a proof  of  a sentence,  say  P-*J,F=P  , in  no  way 
constitutes  a proof  of  any  similar  sentence  ( such  as  |-  CKTJFsQ  ) which  differs 
from  the  former  only  in  the  naming  of  free  variables  (which  are  not  free  in  the 
axioms).  However,  it  is  clear  that  the  ability  to  perform  some  renaming  is  absolutely 
necessary  lor  a smooth  system.  In  the  LCf  system  such  inferences  are  performed 
via  the  theorem  mechanism. 

At  any  point  in  a proof,  a step  may  be  given  theorem,  status  and  the 
sentence  that  the  step  denotes  acquires  a name  and  is  tagged  with  the  names  of  the 
axioms  that  have  been  already  introduced  in  the  proof.  There  are,  of  course,  two 
parts  to  a theorem:  an  antecedent  WFF  and  a consequent  WFF.  The  antecedent  is 
lh*  W F^  denoting  aH  dependencies  and  the  consequent  is  the  WFF  part  of  the  step. 
When  the  user  desires  to  use  a theorem,  he  may  have  the  system  change 


25 


• *.?  33 


; a 


•-1 1 


§ i 


| M 


y| 


I i 


4 -75 


I 

4 I 

3 


i 9 

a ,1 


*#,  -.*'  !'■-'  1 


(throughout  the  theorem)  any  free  variable  (that  is  not  free  in  any  of  the 
appropriate  axioms)  to  any  term  (a  process  called  instantiation),  and  by 
providing  steps  which  when  conjoined  match  the  antecedent  of  the  theorem,  he  may 
infer  the  consequent  of  the  theorem.  The  dependencies  part  of  the  new  step  is  the 
union  of  the  dependencies  of  the  steps  used  to  match  the  antecedent.  It  should  be 
noted  that  the  user  does  not  have  to  type  any  instantiations  that  the  machine  can 
deduce  fi  om  the  list  of  steps  which  must  match  the  antecedent. 


3.3.4.  Simplification: 

As  an  introduction  to  simplification,  imagine  we  have  three  steps  of  a proof: 


(n  1) 

Va.  F(a)  - a 

(dl) 

(n2) 

Vb.  G(  b)  s H(b) 

(d2) 

(n3) 

M a F(G(F(N))) 

(d3) 

It  should  be  clear  that  we  can  proceed  (using  only  features  that  have  been 
discussed  already)  to  a step  which  contains  the  WFF  M s H(N)  and  has 
dependencies  dl  U <12  U <13.  We  might  easily  proceed  through  intermediate  steps 
which  state  M - F(G(N))  and  M •-  F(H(N)) . None  of  the  proofs  will  be  very  short  and 
the  steps  involved  will  probably  help  to  obscure  perhaps  more  interesting  parts  of 
the  total  proof. 

In  the  LCF  system  sets  of  equalities  (called  'simpsets’)  are  maintained  (by 
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the  user  with  help  from  the  machine)  to  help  in  the  automation  of  such  sequences  of 


simplifying  rube  fit  uUo'?e.  When  the  simptUteatton  mechanism  Js  Invoked,  the  Hem 


(which  may  be  a goal,  a step  or  a term)  to  be  ’simplified’  is  scanned  recursively  (top 


down,  left  to  right)  for  a subterm  which  'matches’  the  left  hand  side  of  an  equality  in 


the  current  simpset.  When  such  a match  is  found  the  right  hand  side  of  the  equality 


is  used  to  generate  a replacement  for  the  subterm.  This  simplification  process 


continues  until  no  subterms  in  the  item  can  be  matched  to  anything  in  the  simpset. 


When  an  AWFF  from  a step  is  'put  in’  a simpset  and  it  has  the  form 


VX|  x2  ....  xn.  A s B , the  'universally  quantified’  variables  <x,,  x2,  ..  xn)  are  replaced 


in  A n E by  'metavariables’  (a,,  w2.  •••  «ft)  and  the  new  AWFF  A1  a B1  is  added  to 


the  bimpoet.  The  raison  d'etre  for  metavariables  is  that  they  will  match  any  term. 


Thus,  if  the  equality  Va.  F(a)=a  is  put  in,  ’a’  becomes  a metavariable  and,  for  any 


term  T,  occurences  of  'F(t)’  will  be  'matched’  and  replaced  by  't\ 


Adding  a step  to  the  SIMPSET  amounts  to  adding  each  of  the  equalities 


(AWFFs)  that  constitute  the  WFF.  Steps  in  the  simpset  carry  indication  of  their 


dep**xtenrmj  and  as  a sWpJifkaltorv  proceeds  o cumulative  union  is  kept  lo  which 


the  dependencies  of  steps  used  are  added;  this  union  will  be  contained  in  the 


dependencies  of  any  step  generated  as  a result  cf  the  simplification. 


Theorems  with  no  antecedents  go  into  simpsets  just  as  steps  do  except 


that  thert  are  no  dependencies  and  any  *re£  variafcJas  flhal  are  not  free  in  the 


appropriate  axioms)  are  also  made  into  metavariables. 


Theorems  with  antecedents  may  be  put  in  a simpset,  ard  when  they  are 
used  by  the  simplifier  the  phenomenon  is  known  as  conditional  simplification. 
Suppose  the  theorem  F(a)-G(b)  H H(a,b)=T  (where  variables  *a’/b’  are  not 
free  in  the  axioms)  is  put  in  the  simpset.  The  ’a’  and  the  V become  metavariables 
and  the  theorem  is  considered  when  a subterm  (of  a term  being  simplified)  is  of  the 
form  " H(*,*)  ".  Suppose  the  term  matched  is  H(s,t)  . What  the  simplifer  does, 
instead  of  simply  replacing  the  term  by  T (as  it  would  in  the  absence  of  an 
antecedent),  is  to  attempt  to  verify  the  antecedents  of  the  theorem  by  simplification. 
If  the  simplifier  succeeds  in  checking  the  conditions  of  the  theorem  it  performs  the 
replacement  called  for  by  the  consequent.  There  are  depth  bounds  on  the  recursion 
in  connection  with  this  conditional  simplification  device. 

Steps  of  the  proof  may  also  be  conditional  simplification  rules.  A WFF  in  a 
step  ouch  as  Vx.  p(x)s  F(x)  » G(x) , when  added  to  the  SIMPSET,  is  inserted  in 
two  ways  - both  using  one  metavariable  First  way:  the  left  hand  side  is 
"p</0-»F(/?),r  and  the  right  hand  side  is  "p(/?)-G(/?),r  . Second  way:  the  left  and 

right  sides  are  "F(/0"  and  "G(/0"  respectively  but  there  is  also  a condition  to  be 
checked  - "p{/?)-T". 


wmmms&mQm 
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3.3,5.  Prefix  Stripping; 

When  a GOAL  is  an  AWFF  with  several  prefixes  ( Vx.  a(x)*  Vy  z.  A®B  has 
four  prefixes)  the  natural  way  to  attack  it  is  by  a series  of  abstractions  (to  remove 
outside  universal  quantifiers)  and  cases  arguments  (to  remove  relati visations)  where 
two  cases  are  trivial.  This  action  can  be  performed  in  a single  step  by  means  of  the 
PREF  tactic.  Abstractions  are  done  automatically  and  a step  is  generated  which 
corresponds  to  the  nontrivial  case  of  each  relati visation.  If  the  goal  is  actually 
achieved  by  the  method  then  the  cases  steps  are  deleted. 

For  example,  if  the  goal  were  Vx.  A(x)=>  Vy.  B(y)=>  F(x,y)=G(x,y)  then  the 
assumption  steps  generated  and  put  in  the  simpset  would  be  A(x)sJ  and  B(y)sJ  ; 
the  subgoal  would  be  F(x,y) - G(x,y)  . 


3.4.  Examples  of  LCF  System  Proofs! 


Before  considering  a significant  example  note  that  example  1 of  Chapter  2 
is  a one  step  proof  - namely,  invocation  of  the  'Equivalence  rule’. 


3.4.1.  AeB,  FeG  b F( A) sG(B)  . 

This  is  the  other  example  of  Chapter  2 and  is  much  less  painful  using  the 
LCF  system.  The  text  below  is  a conversation  with  the  program.  Each  command  to 
the  system  (the  user’s  contribution  to  the  interaction)  follows  a prompt  of  5 stars 
and  terminates  with  a semicolon.  The  integers  are  step  numbers. 
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*****  ASSUME  AeB,FeG; 

1 A e B (1) 

2 F e G (2) 

*****  APPL  F,  1 ; 

3 F( A)  e F(B>  (1) 

*****  APPL  2,B; 

4 F(B)  e G(B)  (2) 

*****  TRANS  3,4; 

5 F(A)  e G(B)  (1  2) 

*****  THEOREM  MONOl:  -; 


THEOREM  MONOl:  F(A)  e G(B) 
ASSUME 
A e B, 

F e G 


3.4.2.  (P-1,F)~F  h P:  F 

Thio  particular  proof  would  already  be  something  like  fifty  steps  in  Pure 
LCF.  The  material  shown,  this  time,  is  not  the  whole  record  of  the  interaction  but 
just  the  commands  typed  by  the  user  and  the  proof  that  LCF  constructs. 


ASSUME  P-*i,F-F; 

GOAL  P -F; 

TRY  CASES  P; 

TRY  1;  SIMPL  1 BY  QED; 
TRY  2;  SIMPL  1 BY  QED; 
TRY  3 SIMPL; 
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1 P-*1,F  - F (1)  — ASSUME. 
TRY  «1  P - F CASES  P. 


|TRY#1»1  P = F : SASSUME  P = T 
|2  P - T <2)  — SASSUME. 

|3  1 « F (12)  — SIMPL  1 BY  2 . 


|TRY  «1«2  P 3 F : SASSUME  P*1 
|4  P n i (4)  — SASSUME. 

|5  1 ^ F (14)  — SIMPL  1 BY  4. 


|TRY«1«3  P = F : SASSUME  P = F 
|6  P = F (6)  — SASSUME. 


7 P a F (1)  — CASES  P 3 5 6. 


Notes: 


The  goal  structure  is  reflected  by  the  boxes. 

The  goal  is  printed  at  the  top  of  the  box. 

The  last  line  of  the  box  is  the  established  goal  or 
a contradictory  WFF. 


ii) 


The  command  "TRY  CASES  P"  caused  the  "P=F"  goal  to 
split  to  3 subgoals: 


P-F  SASSUME  P=T 
P”F  SASSUME  P=l 
P“F  SASSUME  P=F 


in) 


A QED  command,  when  the  current  step  is  a contradiction, 
renders  the  goal  under  trial  established. 


iv) 


A SASSUME(W)  command  causes  WFF  W to  be  added 
to  the  simpset  after  it  is  ASSUMEd. 
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3.5.  Concrete  Representation: 


v> 


It  is  unusual  for  computer  input  character  sets  to  contain  many  of  the 
logical  symbols  that  we  need  and,  although  the  machine  at  the  Stanford  A.I.  Project 
is  exceptional  in  this  respect,  it  is  missing  some  symbols  we  have  used.  On  that 
machine  (where  the  LCF  system  lives)  the  following  representations  are  used  for 
characters  which  do  not  appear  on  the  keyboard: 


n is  represented  by  a 

1 is  represented  by  UU 

- is  represented  by  c 

* is  represented  by  :: 

T is  represented  by  TT 

F is  represented  by  FF 


The  point  of  mentioning  this  mat'  “ is  that  the  concrete  representations  of 
these  characters  have  appeared  in  published  works  where  publication  language 
snould  have  been  used. 
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CHAPTER  4 


The  Mathematical  Environment 


We  present  here  a brief  account  of  those  parts  of  [7]  which  are  relevent 
to  the  LISP  semantics  experiments  That  paper  discusses  the  rigorous  development 
of  theories  of  propositional  logic,  integer  arithmetic,  lists  and  finite  sets.  It  provides 
thd  axiomatic  battc  for  a Itrary  of  clcndard  theorems  Irorn  thus*  various  theories 
as  well  as  a collection  of  results  (not  depending  on  axioms)  which  are  useful  when 
working  with  the  LCF  system. 

In  proving  theorems  about  the  meanings  (and  other  properties)  of  various 
LISP  functions,  it  is  necessary  to  make  use  of  a substantial  number  of  results  from 
arithmetic.  Also,  of  course,  the  theory  of  lists  is  fundamental  to  the  representation 
of  LISP  functions  and  the  data  they  manipulate.  The  set  theory  of  [7]  was  not 
required  as  background  mathematics.  Moreover,  it  was  convenient  to  avoid  using 
the  Irani  T*nt  cf  propositional  logic  (thus  space  was  saved  since  the  theorems  were 
not  required). 

We  proceed,  in  this  summary,  by  giving  the  axiomatic  bases  for  each  of  the 
various  aspects  of  the  environment  together  with  some  indication  of  the  scope  and 
depth  of  the  corresponding  sections  of  the  library  of  theorems.  As  an  indication  of 
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the  numbers  of  theorems  involved,  we  note  that  the  number  given  in  [7]  is  about 
1000  and  about  400  of  these  were  selected  for  use  in  the  LISP  experiments.  As 
was  anticipated,  this  body  of  theorems  needed  to  be  extended  by  the  addition  of 
some  other  useful  lemmas.  About  40  such  extra  results  were  added  to  the 
environment  (all  having  very  short  proofs). 

The  domain  of  individuals  <DJ  is  thought  of  as  partitioned  into  subdomains 
which  correspond  to  data  types.  These  subdomains  are  characterised  by  type- 


predicates  (functions  of  LCF  type  (ind-*tr)  ).  For  example  the  predicate  'isint’ 
(axiomatised  below)  gives  T on  individuals  which  are  supposed  to  be  integers  and  1 
or  F on  all  else  in  D,nd. 


4.1.  Axiom  Free  Theorems  in  LCF: 

The  theorems  (or  classes  of  theorems)  in  the  following  list  depend  on  no 
(nonlogical)  axioms.  None  is  very  deep  but  they  find  frequent  use. 


i) 

H [XX.l]  3 1 

ii) 

H Vp.  p->T,F  = p 

iii) 

H Vp.  p-»i,i  s i 

iv) 

x e 1 H x 3 1 

v) 

F(X)«1  H F(l)-1 

vi) 

P(D  - T H P 3 [xx.TT] 
P(D  = F H P 3 [xx.F] 

vii) 

P(X)-=T,  P(Y)sF  H P(J>1 

34 


... 


o 


1 1. 


tUrSKtf M «tf5  'tmmfl  »! 


tew^Vi^TrKpatniftagcgyarea^d^^ 


viii) 

F1eF2,A1eA2  b FI < A 1 ) 
F1eF2,  A1eA2,B1eB2  b 
and  so  on. 

ix) 

P-*T,i  s T b P s X 
P-*F,T  = 1 b Pal 
etc. 

x* 

P-*T,Q  = F f-  P = F 
P-Q.T  = F b Q * F 

etc. 

xi) 

G a F(G)  b [^g-F<g>]  e G 

xii) 

P-T.T  ® F b T a F 
P-F.1  ■ T b T 3 F 
etc. 

Note  that  (i),  (ii),  (iii)  are  suitable  for  permanent  SIMPSET  residence  and 
that  (xii)  is  good  for  deriving  contradictions. 


4.2.  Equality  and  Definedness: 


We  are  easily  able  to  axiomatise  a sensible  equality  predicate  ( = ) and  a 
definedness  predicate  { <3 ).  We  want  to  call  all  individuals  except  1 defined;  that 
is,  if  x is  in  Dind  then  we  want  *x)hT  if  and  only  if  x is  not  1.  The  desired 
equality  predicate  must  be  T or  F on  all  pairs  of  defined  elements  of  Djnd,  must  be 
reflexive  on  defined  elements  and  must  be  such  that  (x=y)Ej  indicates  x*y.  In 
postulating  such  a two  place  predicate  we  make  a commitment  that  Dind  should  be 
discrete  (flat). 

We  axiomatise  *=’  and  define  ’a*  in  terms  of  it  as  follows; 


35 


t- 


i 


B 


AXIOM  EQ 

Vx.  (x=x)-*x,l  ® x 
Vx  y.  (x=y)=>  xay, 

Vx  y.  (x=x)-*((y=y)-*T,l),l  3 (x=y)-*T,l 

(1=1)  h 1 


cl  S 


[XX.  X=X  ] 


We  use  the  vertical  bars  ( ||  ) down  the  left  hand  edge  of  the  page  to 
indicate  axioms. 

As  a technical  aside  to  the  critical  reader,  note  that  the  fourth  of  these 
axioms  is  not  necessary  if  we  can  talk  about  some  element  of  Djnd  other  than  Ij  in 
that  case  we  can  deduce  '(1=1)^!’  by  monotonicity. 

Although  (X=Y)  T h XaY  is  the  fundamental  property  of  the  equality 
predicate,  should  not  be  confused  with  the  latter  is  not  a computable 
function. 

Both  of  these  functions  (definedness  and  computable  equality)  have  proved 
extremely  useful  and  the  following  are  the  theorems  (or  groups  of  theorems)  that 
are  to  be  found  in  the  environment  (with  comments);- 


i) 

ii) 


iii) 


f*  c'(l)  3 1 
|-  Vx.  x=l  = 1 
H Vx.  l=x  3 1 
f-  Vx.  (x=x)  3 i(x) 


(Strictness  of  d) 
(Strictness  of  '=’) 


(Reflexi vity  of  '=’) 


iv) 

v) 


;i(X)3i  |.  x-=i 
X=Ysl,  cl(X):=T  h Ysi 
X=Y=~F  |-  ci(X)hT 
etc. 


(Totality  of  '<3’) 
(Totality  of  '=’) 
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Vi) 

X=Y=T  h X^Y 

(Conversion  to  '«*’) 

vii) 

X-Y,  ci(X)aJ  H X=YsJ 

(Conversion  from  ’■’) 

viii) 

h X=XaT 

(Reflexivity  again) 
(Commutativity  of  '=’) 

ix) 

(X=Y)sTr  }-  (Y(<=X)=Tr 

x) 

3(X)«T,  XsY  f*  X=Y 

(Discreteness  of  Dind) 

xi) 

F(X)=F(Y)~F  V X=YnF 
fr  FUKl 

P(X)aT,  P(Y)=F  h X=Y-F 

xii) 

ci(X)-F  [■  T=F 

xiii) 

(X=X)-F  h TSF 

xiv) 

(X=Y)si,  d00-T,  a(Y)=T  h Jsf 

xv) 

(X=Y)=F,  XeY  h T=F 

Note  that  the  theorems  suitable  for  permanent  simpset  residence  form  the 
first  group  (i-iii)  and  those  which  are  contradiction  oriented  have  also  been  grouped 
together  (as  xii-xv/. 


4.3.  Natural  Numbers'! 


Although  the  natural  numbers  are  not  used,  as  such,  in  the  LISP 
experiments,  and  although  the  theorems  concerning  these  objects  have  been 
removed  from  the  environment  as  described  in  [7],  the  foundations  for  the 
construction  of  the  integers  is  the  axiomatisation  of  natural  numbers.  The 
interpretations  intended  for  the  constants  (0,  1,  Z,  isnat,  succ,  pred)  are  the  natural 
ones.  Note  that  'isnaf  is  a type  predicate  which  gives  T on  natural  numbers  and  1 
on  everything  else. 


I 


I: 
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AXIOM  NN; 

Z [xx.  x=0] 

Z(O)  » T 

isnat  •*  f/iF.  [xx.  Z(x)-*T,F(pred(x))  ]] 
Vx.  isnat(x)=>  Z(x)-0,succ(pred(x))  = X 
Vx.  isnat(x)*  Z(succ(x))  h IF 
Vx.  isnat(x)*  pred(succ(x))  b x 

1 = succ(O) 

2 = succ( 1) 


Although  this  set  of  axioms  is  simply  a building  block  (in  the  current 
context),  we  give  a set  of  derivable  theorems  which  correspond  to  the  traditional 
Peano  Postulates.  This  indicates  that  one  should  expect  all  the  usual  results  of 
basic  number  theory  to  be  provable. 


isnat(O)  ~ T 

isnat(X)-T  |-  isnat(succ(X))-T 

isnat(X)-T  H (succ(X)=0)nF 

isnat(X)=T,  isnat(Y)=T,  succ(X)-succ(Y)  f-  X^Y 

6(0)'=T,  Vx.  isnat(x)*  g(x)s>  g(succ(x))=T 

H Vx.  isnat(x)*  g(x)sj 


4.4.  The  Integers: 


The  following  axioms  specify  more  completely  the  functions  'pred’  and 
'succ?  (see  above)  and  introduce  the  functions  'rnns\  ’pos’  and  'isint\ 


38 


BWSWKfi  * a «9Ksas*as»ss!*^^!8S3!HW®^ISiKISM®j^:i 


r 

tf 


I 


it’! 


jJHfj 


iy 


<U 


V* 


AXIOM  INT: 

Vx.  isnat(x)=>  pos(x)  s Z(x)-»F,T 

Vx.  pos(x)*  isnat(x)  = T 

Vx.  pos(mns(x))  = pos(x)-*Fi  Z(x)-»F,T 

Vx.  pos(x)->T,T  s i$int(x)-»T,l 

Vx.  isint(x)-*mns(mns(x)),mns(x)  a isint(x)-»x,l 

Vx.  succ(x)  3 mns(pred(mns(x))) 

Vx.  predfx)  * mfls(sutc(mrt$(x))) 

[xx.  isint(x)-»T,T]  ■ 3 


We  first  show  the  results  of  applying  the  various  functions  to  the  small 
integers  <Orl, 2)  and  to  the  undefined  element  of  Djnd. 

i)  isint<0)sT,  isint(l)=T,  isint(2)sj,  isint(l)al 
pOS(0)»F,  P0S<1)=T,  P05<2)sT,  pos(l)«l 
Z(0)*T,  Z(11HF,  Z(2)aF,  ZU)»1 
a<0)-T,  3(1)-T,  3<2)aT,  0(l)3i 

succ(0)sl,  SUCC<1)<*2,  SUCC<l)sl 
pred(l)sO,  pred(2)sl,  pred(l)sl 
mnsfOl^O,  mns(l)sl 


ii) 

Hi) 

iv) 

v) 

vi) 

vii) 


The  derived  theorems  are  too  numerous  to  list  but  we  now  give  some 
examples  selected  to  give  a flavor  of  them. 


i) 

ii) 


isint(XbF  |-  pos(X)sl 
isint(X)^F  H succ(X)=l 


f-  Vx.  isint(succ(x))  = isint(x)-»T,l 
h Vx.  Z(mns(x))  = isint(x)->Z(x),l 
h Vx.  mns(pred(x))  - succ(mns(x)) 
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iii)  pos(X)--T  H isint(X)--T 
isint(X) --T  f-  ji(X)-T 
a(succ(X))r=T  \.  isint(X)sT 

iv)  isint(X)  =T,  pos(X)si  h T=F 
isint(X)~T,  Z(X)si  f.  T-F 


4.5.  Integer  Arithmetic: 


LCF  is  such  that  once  we  have  axiomatised  a structure  then  many  of  the 
functions  we  may  be  interested  in  can  be  written  as  terms  of  the  logic.  We  give 
below  definitions  of  the  various  operations  of  arithmetic  that  were  appropriate  to 
proving  things  about  the  LISP  subsets  that  we  are  interested  in. 


AXIOM  ARITH 

+ - [>G.  [xx  y.  Z(y)  ->  (isint(x)-x,!), 

pos(y)  - G(succ(x),pred(y)),  G(pred(x),succ(y))]] 

- - [xx  y.  x+mns(y)] 

* ~ [/iG.  [xx  y.  Z(y)  -»  (isint(x)-‘0,l), 

pos(y)  -*  G(x,pred(y))+x,  G(x,succ(y))-x  ]] 

> s [xx  y-  pos(x-y)] 

- [xx  y.  Z(x-y)  - T,  pos(x-y)] 


Many  other  useful  and  traditional  arithmetic  functions  are  defined  in  [7] 
including  division,  remainder-on-division  and  bounded-existential  and  bounded- 
universal  quantifiers  for  integer  predicates. 

O 
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It  is  readily  proved  that  all  these  functions  are  total  over  the  integers  but 
Jeimed  only  on  the  integers;  these  facts  find  expression  in  many  theorems  in  the 
environment.  Apart  from  all  the  well-known  basic  properties  of  these  functions  (such 
as  commutativity  of  V and  V or  the  transitivity  of  V and  V)  being  given,  a large 
number  of  simple  relations  between  2 or  3 of  the  constants  (l,  0,  1,  succ,  +,  pred,  -, 
*>  -•  >*  mns)  are  S'ven  as  theorems.  In  fact,  the  environment  contains  over  150  such 
theorems  and  there  seems  no  way  of  categorising  them  so  we  can  even  list 
representative  theorems.  However,  it  has  turned  out  that  this  library  has  been 
adequate  |,o  hafitHe  the  modest  requirements  of  the  LISP  project. 


4.6.  A Theory  of  Lists: 


In  [7]  there  is  an  extensive  treatment  of  lists  based  on  the  axioms  below. 
The  treatment  was  substantially  LlSP-inspirtd  and  developed  via  a treatment  of 
certain  abstract  objects  that  are  similar  to  S-expressions.  In  that  report  they  were 
called  S-expressions  but  that  has  turned  out  to  be  a bad  mistake  for  the  current 
work  so  we  will  call  them  PONs  (since  a PON  is  either  a Pair  Or  NIL).  There  is  a 
pairing  function  (like  CONS)  and  two  selector  functions  Chd’  and  ftP  - like  CAR  and 
CDR)  for  analysing  pairs.  As  in  LISP  an  atom  is  anything  that  is  not  a pair  and 
repeated  selection  in  a PON  eventually  yields  an  atom. 
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AXIOM  LIST 

ispon(l)  --s  1 

ispon(NIL)  a T 

null  [xx.  x-NIL] 

atom  | xx.  ispon(x)-‘null(x),T] 

Vx.  atom(x)*  hd(x)  « j. 

Vx.  atom{x)=>  tl(x)  * l 

Vx  y.  hd(x»y)  - rXyHx.l 

Vx  y.  tl(x»y)  s ci(x)-7,l 

Vx.  hd(xHI(x)  = atom(x)-l,x 

'■'  ” rMG.[xx.atom{x)-T,G(hd{x))-*G(tl(x)),lj] 

islist  h [/iG.[xx.  null(xHT,atom(x)->F,G(tl(x))]] 


Wu  first  mention  that  all  of  the  functions  mentioned  in  the  axioms  are  strict 


and  that  ispon,  atom  iK  null’  are  total.  We  give  just  a few  simple  results  of  the 


theory  (remembering  that  moot  of  the  theorems  in  the  environment  are  quite 


simple): 


c'(Y)-T  f-  Vx.  hd(x»Y)*x 


c'(X)~T  |-  Vy.  tl(X*y)ny 


hd(X)) -T  h atom(X)-F 


atom(X)”F  h d<hd<X>>^T 


H Vx.  <i(tl(x))s<H(hd(x)) 


null(X»Y)r  T f-  T-F 


hd(X)-:X  H Xnl 


H Vx  y.  islist(x«y)=ci(x)-*islist(y),l 


vly 


i^’sswf^'irtKs.T,  *imgt33£im 


*vnra*t3ib*  MAmet&mpursmi, 


ix) 


G(NIL)sT,  Vx  y,  a{x)*  istist(y)*  G(y)*  G(x*y)sT 
h Vx.  islist(x)*  G(x)a? 


x) 


Vx.  atom(x)*  G(x)=T,  Vx  y.  G(x)*  G(y>*  G(x»y)sT 
h Vx.  tfx>*  G(x)hT 


We  now  come  to  present  a selection  of  the  various  list  operations  that 
were  defined  in  [7];  we  define  here  only  those  operations  that  we  require  for  the 
experiments  in  this  thesis. 


AXIOM  LOP 

K s l>G.[xx  y.  nulKxHy,  hd(x)-G(tl(x),y)]] 


mem  = [xx  y,  <i(x)-»ORmap(y,[xz.x=z]),l] 

ORmap  a [/iG.[xx  p.  islist(x)-* 

(null(x)-F,  p(hd(x»-+T,  G(tl(x),p)),i]] 


assoc  a [>G.[xx  a.  a(x)-»  islist(y)-*  null(y)— NIL, 
(x=hd(hd(y)))-*hd(y),  G(x,tl(y)),  1,1  ]] 


length  a [mG.[\x.  null(x)-*0,  succ(G(tl(x)))]] 


W is  the  append  function  for  lists  and  ’mem’  is  membership  in  a list;  ‘assoc’ 
and  ‘length’  need  no  introduction.  We  do  not  give  any  properties  of  these  functions 
but  simply  say  that  most  of  the  results  (about  the  functions)  which  were  needed, 
were  already  available  when  required  in  the  LISP  experiments. 
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CHAPTER  5 

Notation,  Denotation  and  the  Nature  of  LISP  Expressions 


5.1.  Notation  and  Denotation! 


Wc  recoil,  here,  the  distinction  between  numbers  and  numerals.  Numbers 
are  abstract  (mathematical)  objects  while  numerals  are  expressions  in  certain 
languages;  Numerals  are  used  to  denote  numbers  while  numbers  provide  the 
interpretations  for  numerals.  The  common  number/numeral  confusion  arises  because 
of  the  usual  identification  of  numbers  with  the  numerals  of  the  positional-notation 
decimal  number  system  (actually  a numeral  system).  Remember,  every  numeral 
denotes-  come  number  and  is  consequently  notation  for  the  number! 

Chapter  4 described  an  environment  within  which  the  current  experiments 
on  a LISP  semantics  can  be  performed.  Some  very  important  classes  of  abstract 
objects  ore  therein  developed:  - integers,  lists  and  ordered  pairs.  A treatment  of 
LISP  must  contain  some  discussion  of  notations  for  these  abstract  entities  but  we 
find  our  vocabulary  is  not  rich  enough:  clearly  'list’  corresponds  to  'number’  but  we 
need  a word  to  correspond  to  'numeral’.  We  shall  adopt  the  convention  that  when 
we  have  a name  for  a class  of  abstract  objects  we  shall  write  it  predominantly 
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lower  ease  and  when  we  wish  to  discuss  the  class  of  expressions  that  represent  the 
abstract  objects  we  will  use  all  capitals.  For  example  an  S-EXPRESSION  will  be  an 
expression  in  a language  that  denotes  a certain  S-expression  (an  abstract  object). 

If  we  have  a class  Pqr  of  abstract  objects  and  a class  PQR  of 
representations  for  elements  of  Pqr,  then  there  is  a semantic  function,  (call  it  Den) 
which  maps  expressions  into  the  objects  they  denote.  We  will  refer  to  Den  as  a 
denotation  function,  There  are  also  functions  which  map  each  abstract  object 
into  an  expression  of  the  language  we  are  using  to  discuss  elements  of  Pqr;  we  call 
these  functions  notation  functions. 

Just  as  "02",  "0002"  and  "2"  are  different  notations  for  the  same  number, 
the  LISP  S-EXPRESSIONs  "(A  B)",  "(A  . (B))",  "(A  . (B  . NIL))"  and  "(A  . (B  . ( )))" 
denote  the  same  S-expression.  The  fact  that  systems  of  notation  are  often 
redundant  in  this  way  means  that  denotation  functions  are  in  general  many  to  one.  It 
is  a fundamental  property  that  if  N is  any  notation  function  for  Pqr  then  for  all  X in 
Pqr,  Dent  N(  X ))  = X . Also,  the  function  [\x.  N(Den(  x ))]  selects  canonical 
representations. 


5.2.  Abstract  Syntax 


The  term  syntax  usually  refers  to  rules  (perhaps  phrased  in  BNF)  which 
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specify  which  strings  of  symbols  are  legal  in  some  language  and  what  the  structures 
of  the  language  are.  McCarthy  calls  this  'concrete’  syntax.  'Abstract’  syntax  also 
describes  the  structures  of  the  language  but  without  saying  how  the  structures  are 
represented  by  strings  of  symbols. 

Abstract  syntax  comes  in  two  flavours:-  'analytic’  and  'synthetic’.  Analytic 
abstract  syntax  makes  use  of  discriminators  such  as  'issum’  and  'isassignment’ 
and  also  selector  functions  to  access  components  of  syntactic  entities.  Synthetic 

abstract  syntax  deals  in  constructor  functions  such  as  'mksum’  and 
'mkassignrnent’. 

Abstract  syntax  is  no  stranger  to  the  LCF  project  - [5]  and  [6]  depend  on 
it.  We  now  make  the  claim  that  defining  denotation  and  notation  functions  (in  LCF)  in- 
terms of  McCarthy’s  notion  of  abstract  syntax  is  quite  straightforward.  In  the  next 
section  this  assertion  will  be  illustrated  with  definitions  of  such  functions  for  $» 
expressions. 


5.3.  S -expressions! 


As  mentioned  in  Chapter  4,  the  notion  of  S-expression  developed  in  [7]  is 
unsatisfactory  for  our  purposes.  It  is,  therefore,  part  of  the  task  of  axiomatising 
subsets  of  LISP  to  define  precisely  what  constitutes  an  S-expression.  At  this  point, 
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we  can  outline  what  makes  one:  a certain  subset  of  the  atoms  of  Dmd  will  be 


S-expressions  and  if  we  know  X and  Y are  S-expressions  then  X*Y  is  one  too.  We 


cannot  be  specific  about  what  the  subset  is,  at  this  point,  but  it  certainly  will  contain 


NIL  and  certain  names  or  identifiers.  Thus  we  are  going  to  identify  the  LISP  'cons’ 


function  with  the  pairing  function  that  we  know  so  much  about.  Similarly,  we 


identify  'car  and  'cdr  with  'hd'  and  ’tl’  respectively. 


We  are  now  in  a position  to  exhibit  denotation  and  notation  functions  for 


S-expressions.  We  use  abstract  syntax  (both  analytic  and  synthetic)  in  the 


definition.  We  suppose,  for  the  coke  o!  the  example,  that  S-expressions  are  those 


individuals  that  satisfy  the  type-predicate: 


isSexprn  3 [mg.  [\x.  isintfxHT,  i$name(x)-*T,  null(x)  -+T, 

atom(x)-*F,  G(hd(x))-*G(tl(x»,  F]] . 


We  call  the  denotation  function  for  S-EXPRESSIONS  'Sexprnof’  and  the 


notation  function  for  S-expressions  'mkSEXPRN’: 


Sexprnof  « [MG.[\X.islNTEGER(X)  -*  integerof(X), 
isNAME(X)  -*  nameof(X), 
isNIL(X)  - NIL, 

isPAIR(X)  ■«  G(lcftof(X))'G( right of(X)), 
isLIST(X)  -»  G(firstof(X))'G(restof(X)), 
1 ]] 


mkSEXPRN  3 |>G.[xx.isint(x)  -*  mklNTEGER(x), 
isnarnc(x)  -♦  mkNAME(x), 

(x=NIL)  -*  mkNIL, 

isSexprn(x)  -*  mkPAIR(G(hd(x)),G(tl(x))), 

HI 
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The  functions  'isINTEGER’,  ’isNAME’,  'ioNIL’,  -isPAIR'  end  ’isLIST’  are  analytic 
syntax  discriminators,  Teftof’,  Vightof’,  'firslof  and  'lastof’  are  analytic  syntax 
selector  functions,  'mkPAIR’  and  'mkNIL’  are  synthetic  syntax  constructor  functions. 
Of  course,  we  have  just  passed  the  buck  since  'integerof’  and  'nameof’  are  also 
denotation  functions  and  'mkINTEGER’  and  ‘rnkNAME*  are  notation  functions. 

If  in  this  example  we  have  appropriate  results  about  the  lower  level 
functions  such  as 


Vx.  isname(x)*  nameof{  mkNAME(x))  = x , 
Vx.  islNTEGER(x)*  isint(integerof(x))  = X , 
Vx.  isname(x)*  islNTEGER(  mkNAME(x))  = F 


then  we  are  easily  able  to  prove 

Vx.  isSexprn(x)*  Sexprnof(mkSEXPRN(x))  s x 


5.4.  LISP  Expressions! 


Since  this  thesis  is  concerned  with  the  semantics  of  the  programming 
language  LISP,  we  must  inevitably  describe  what  sort  of  mathematical  object  a LISP 
progtam  (or  a LISP  function  ) is.  We  must  conclude  that,  because  of  the 
indistinguishability  of  program  and  data  in  LISP,  all  expressions  in  the  language 
(whether  they  are  intended  for  'execution’  or  not)  must  have  the  same  type;  they 

must  be  members  of  Dmd  . In  fact  all  LISP  functions,  arguments  and  results  will  be 
S-EXPRESSIONs. 
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What  we  are  looking  for  when  we  seek  a semantics  for  LISP  is  a function 


kadi  il  LISP!  which  maps  S-EXPRESSJDNS  onto  S-EXPRESSIONS  in  the  same  way  as 


a LISP  interpreter  actually  running  in  a machine.  For  example,  LISP  should  map 


the  S-EXPRESSION 


"(CDR  (CONS  NIL  (QUOTE  X)))" 


onto  the  S-EXPRESSION  "X" . 


A necessary  property  of  such  a LISP  function  is  that  if  S-EXPRESSIONS 


'X’  and  ’Y’  denote  the  same  S-expression  then  the  S-EXPRESSIONS  ’LISP(X)’  and 


'LISP(Y)’  must  be  the  same. 


We  now  point  out  a method  of  defining  LISP  indirectly  which  is  very 


important  to  our  work.  What  we  do  is  to  define  an  interpreting  function  ’lisp’  which 


maps  S-expressions  onto  S-expressions  in  the  appropriate  manner.  Then  by  using 


denotation  and  notation  functions  (0  and  N)  we  can  define  LISP  as  a composition 


of  functions; 


LISP  n [xX.  N(lisp(D(X)))] . 


Note  that  the  function  we  get  depends  on  the  particular  choice  of  ’N’  but 


this  is  as  it  should  be.  Because  of  the  way  we  have  defined  LISP  we  have  the 


following  commutative  diagram: 


Now,  if  N,  is  any  (other)  notation  function  for  S-expressions  then  we  should 
be  able  to  prove 

lisp  * [xx.  D(LISP(N,(x)))] 

using  the  basic  relationship  between  denotation  and  notation  functions.  This 
immediately  suggests  that  the  function  ‘lisp’  is  more  fundamental  than  any  particular 
LISP  function  we  might  have. 

From  this  point  on.  therefore,  we  shall  not  be  concerned  with  notation  in 
general  or  S-EXPRESSIONs  in  particular;  all  discussion  will  centre  round 
S-expressions. 


5.4.1.  List  Notation. 

We  mention  one  point  of  notational  convenience.  In  the  LISP  we  all  know 
and  love,  (A  B C)  can  be  thought  of  as  an  abbreviation  of  (A  . (B  . (C  . NIL))).  Just 
for  the  purposes  of  this  document  we  shall  use  a similar  abbreviation  for  lists  but 
we  use  the  distinctive  brackets  and  For  example  (A  B C)  is  an  abbreviation 
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for  A»(B’(C”NIL))  (i.e.  denotes  the  list  containing  A,  B,  C).  Note  that  (A  B C)  is  not  a 
term  of  LCF  since  the  LCF  system  does  not  have  a capability  which  allows 
introduction  of  abbreviations. 


5.4.2.  LISP  Functions: 

We  have  taken  the  position  that  LISP  expressions,  in  general,  and  what  are 
usually  termed  'LISP  Functions’,  in  particular,  are  simply  individuals.  This  raises  the 
question  "Do  'LISP  Functions’,  such  as 

(LAMBDA  (X)  (CAR  (CDR  (CDR  X)))) 

have  any  functional  character  whatsoever?"  . 
Answer:  'LISP  Functions’,  although  simply  LISP  data,  induce  functions  under 
interpretation.  Hence  we  may  sometimes  identify  an  S-expression  with  the  LCF 
function  that  it  induces  under  interpretation.  For  example,  we  will  identify  with  the 
'LISP  Function’  above,  the  LCF  function: 

[\y.lisp(((LAMBDA  (X)  (CAR  (CDR  (CDR  X))))  y))] . 

which  will  turn  out  to  be  simply  the  function  [\y.  hd(tl(tl(y)))] . 
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CHAPTER  6 

An  Axiomatic  Theory  of  Pure  LISP 


6.1.  Extending  the  Environment  for  Names! 


Both  data  and  programs  in  Pure  USP  are  S-expressions  fcuiit  from  NIL  and 
those  atoms  which  are  simply  names  (identifiers).  The  environment  of  Chapter  4 
fiiv^s  lib  seme  pew  (o  manipulate  such  S-expresaions  because  of  their  structure 
but  we  need  to  augment  these  results  so  we  can  we  can  (logically)  talk  about  the 
atoms  in  S-expressions.  In  fact,  we  must  present  axioms  which  further  specify  Dlrid 
to  contain  names  as  well  as  integers  etc.  Not  only  do  we  want  to  talk  about  names 

in  general  but  we  want  to  introduce  certain  specific  names  such  as  T’,  ‘LAMBDA’ 
and  ’CAR’  . 

The  first  four  axioms  for  Pure  LISP  are  then: 


♦♦AXIOM  PL1 : 

isSexprn  = |>F.[\x.  null(x)->T,  isname(xMT, 

atom(x)-»F,G(hd(x)HG(tl(x)),F]] 


♦♦AXIOM  PL2: 

Vx.  isname(x)  -» isint(x)  -»  l,  atom(x)  ■*  x,  i, 
isint(x)  ->  atom(x)  -»  x,  1,  x a x 


♦♦AXIOM  PL3; 

II  Vx.  ci(discr(x))*  i$name(x)3T 
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PLl  simply  expresses  in  LCF  the  definition  of  S-expresslons  for  Pure  LISP 
which  was  given  in  plain  language  above.  Then  PL2  further  specifies  the  structure  of 
thi.  Jum.Tiin  of  injividujs  [D  J as  buing  partianuJ  by  the  name  and  integer  type- 
predicates.  Looking  at  the  consequences  of  these  two  axioms  we  see 


|-  isname(i)  = 1 
isname(X)=i  (•  X - i 
isname(X>3T  H atomfXHT 
isint(X)aT  f-  atom(X)=T 


as  well  as  the  fact  that  names,  integers  and  pairs  (non-atoms)  are  all  distinct.  Finally, 
PL3  introduces  ‘discr’  which  maps  names  onto  integers  and  is  the  basis  of  a compact 
way  of  introducing  specific  names;  we  will  use  it  is  a discriminating  function  to  give 
a total  ordering  for  names  (although  this  fact  is  not  contained  in  the  axiom).  To 
illustrate  its  use  we  just  proceed  with  the  axioms  for  Pure  LISP,  giving  the  one 
which  introduces  the  'reserved  words’. 

**AXI0M  PL4: 


discr(LAMBDA)  > discr(LABEL)  - T, 
discr(LABEL)  > discr(QUOTE)  3 T, 
discr(QUOTE)  > discr(ATOM)  = I, 
discr(ATOM)  > discr(COND)  = T, 
discr(COND)  > discr(CONS) « T, 
discr(CONS)  > discr(CAR)  = T, 
discr(CAR)  > discr(CDR)  3 T, 
discr(CDR)  > discr(EQ)  3 X, 
discr(EQ)  > discr(F)  3 X, 
discr(F)  > discr(T)  3 X 


When  using  the  LCF  system  to  do  the  proofs  discussed,  we  decorated  the 
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specific  names  (QUOTE,  CAR  etc.)  with  a leading  underbar.  Underbar  in  an  identifier 
indicates  that  the  atom  is  a constant  name  in  Djnd  and  mentioned  in  the  axioms. 

However  in  this  r eport  we  will  simply  write  _CAR  as  CAR  . 

* 

It  is  a trivial  exercise  to  show  that  each  of  these  reserved  words  is  a name 
(satisfies  the  Isname’  type-predicate).  Furthermore,  using  the  transitivity  of  V we 
can  easily  show  that  distinct  names  are  unequal.  For  example,  we  can  derive 
discr(CAR)>discr(T)  - T and  hence  CAR=T-F  . 


6.2.  Axioms  for  Interpreting  Pure  LISP: 


As  has  already  been  inferred,  we  will  be  defining  in  this  section,  a function 
’lisp’  which  ‘interprets’  S-expressions  in  the  appropriate  manner.  For  example,  we 
wish  the  function  to  satisfy  the  equations 
lisp( (QUOTE  T))  * T 

lisp(((LAMBDA  (X)  (CONS  X (QUOTE  F)))  (QUOTE  T)))  s T ° F 
where,  of  course,  X is  a name. 


[ 1 2 j contains,  in  order  to  be  precise  about  the  meaning  of  the  language,  an 
interpreter  for  Pure  LISP.  That  interpreter,  which  is  written  in  Pure  LISP,  and  which 
we  reproduce  in  Figure  6.1  (next  page),  is  a collection  of  mutually  recursive 
functions,  the  most  important  of  which  are  ‘eval’  and  'apply’,  ‘eval’  is  a function  of 
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apply[fn;x;a]  = 

[atom[fn]  -»  [eq[fn;CAR]  -»  caarfxl; 

eq[fn;CDR]  ->  cdar[x]; 
eq[fn;CONS]  -*  cons[car[x];cadr[x]]; 
eq[fn;ATOM]  ->  atom[car[x]]j 
eq[fn;EQ]  ■+  eq[car[x];cadr[x]]; 

T -»  apply[eval[fn;a];x;a]]; 
eq[car[fn];LAMBDA]  -* 

eval[caddr[fn])pair\is[cadrrLtn]iX;a]ji 
eq[car[fn];LABEL]  -*  apply[caddr[fn];x; 

ci^4coniy[c3dr[f  n Jjcaddrifr  ] Ja]]  J 


evalO;a]  = 

[atom[e]  •*  cdr[assoc[e;a]]; 
atom[car[e]]  ->  [eq[car[e];QUOTE]  -*  cadr[e]; 

eq[car[e];COND]  -*  evcon[cdr[e];a]j 
7 •*  etpp  I y [ c-ar  [ « > o v u'  «*[  cdr  (e  1 j; 

T -»  apply[car[e]jev|is[cdr[e];a];a]] 


evcon[c;a]  = [eval[caar[c];a]  -»  eval[cadar[e];a]; 
T ->  evcon[cdr[c];a]] 


evlis[m,a]  = [null[m]  •*  NIL; 

T -*  cons[eval[car[m];a];evlis[cdr[m];a]]] 


pair lis[x;y;a]  = [null[x]  -»  a; 

T ->  cons[cons[car[x];car[y]]; 

pairlis[cdr[x];cdr[y];8]]] 


assoc[x;a]  = [equal[caar[a];x]  ->  car[a]; 
T -*  assoc[x;cdr[a]]] 


» ■ J 


I I 


J 


i m 

J 


a a 
| % 


Figure  6.1  - The  Pure  LISP  Interpreter  of  McCarthy. 
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two  arguments:-  a LISP  expression  and  an  association  list  which  is  used  to  hold  the 


bindings  of  variables.  'eval(E,  A)’  gives  the  LISP  interpretation  (the  evaluation)  of 


the  expression  E using  A to  get  the  values  of  variables.  Similarly,  'apply(F,  L,  A)’ 


applies  the  LISP  function  F to  the  list  L of  arguments  again  using  A to  bind  values 


to  variables. 


Now  in  developing  a new  definition  of  Pure  LISP,  we  do  it  in  a way  that 
corresponds  as  closely  as  possible  to  the  McCarthy  interpreter.  In  particular  we  will 
have  LCF  functions  W,  'apply’,  'evils’,  'evcon’  etc.,  each  with  almost  the  same 


structure,  as  the  LISP  function  o.:  the  same  name. 


'eval’  is  the  most  basic  of  the  various  functions  we  propose  since  we  are 


able  to  define  all  the  others  in  terms  of  it: 


♦♦AXIOM  PL 5: 


lisp  - [xe.  eval(e,NIL)  ] 


♦♦AXIOM  PL6; 


apply  - [jiG.  fxfn  x a.  ci(x)-»  islist(a)-» 

(fn-CAR)-  hd(hdfx)), 

(fn=CDR)-k  tl(hd(x)), 

(fn=C0NS)-  hd<x)«hd(tl(x)), 

(fn=AT0M)-  atom(hd(x))  -*  T,  F, 

(fn=EQ)-»  [xx  y.atom(x)-*atom(y)->(x-y),i,i] 

, 4 (hd(x),hd(tl(x)»-*T,F, 

atom(fn)-*  G(eval(fn,a),x,a), 

(hcJ(fn)-LAMBDA)-*  eval<hd(tl<tl<fn))>,  pairlis(hd(tl(fn)),x,a)), 
(hd(fn)=LABEL)-»  G(hd(tl(tl(fn))),x,((hd(tl(fn))*hd(tl(tl(fn))))*a)), 

J-.  if  1 ]] 
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**AXIOM  PL7: 


evcon  h f^G.[xc  a. 

(eval(hd(hd(c)),a)=T)  •*  eval(hd(tl(hd(c))),a), 
(eval(hd(hd<c)),a)=F)  - G(tl(c),a)  , 1]] 


**AXIOM  PLS: 

||  evlis  s [/iG.[xm  a.null(mHNIL,eval(hd(m),a)'G*tl(m),a)]] 


**  AXIOM  PL 9: 

pairlis  s [/iG.[xx  y a.  nuli(x)-*a, 

(hd(x)*hd(y))  • G(tl(x),ti(y),a)]] 


It  remains  only  to  define  'eval’.  inspired  by  the  interpreter  we  want  'eval5 
to  satisfy  the  equation 


eval  » [xe  a.  atom(e)  -*  tl(assoc(e,a)), 
hd(e)=QU0TE)  -»  hd(tl(e)), 

(hd*e)=C0ND)  -*  evcon*tl(e),a), 

apply(hd(e),evlis(tl(e),a),a)] . 


Now  this  equation  is  not  satisfactory  as  a definition  since  it  contains 
references  on  the  right  to  functions  which  depend  on  'eval’;  if  we  adopted  this  we 
would  not  have  a set  of  definitions  but  a set  of  mutually  recursive  equations.  Worse 
yet,  this  set  of  simultaneous  equations,  although  consistent,  does  not  specify  the 
functions  adequately.  An  example  will  show  this;  Consider  the  computation  of 

eval(  (G),  (G«(LAMBDA  NIL  (G))) ) 
through  apply*  G,  NIL,  (G°(LAMBDA  ...)) ) 

and  apply*  (LAMBDA  NIL  (G)),NIL,(G*(LAMBDA...))  ) 

back  to  eval*  (G),  (G<LAMBDA  NIL  (G)))  ) !!! 
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It  is  not  inconsistent  with  the  above  equation,  then,  to  assert,  for  example 
evol(((i),  (G'(LAMBDA  NIL  (G)))  3 T . We  actually  want  our  definition  of  ’eva!’ 
to  specify  the  results  of  all  computations. 

The  solution  is  clear,  we  take  the  definitions  of  'evcon\  'apply’  and  'evlis’ 
and  substitute  them  in  the  above  equation  for  'eval’;  we  then  take  the  fixed  point  of 
the  right  hand  side;  lastly  we  add  a leading  condition  to  ensure  strictness.  We 
present  the  resulting  axiom  ( PL  1 0 ) as  Figure  6.2  (next  page).  With  this  definition 
of  'eval’  we  get  as  a theorem 

eval  3 [\e  a.  islist(a)-* 

(atom(e)  -+  tl(assoc(e,a))), 

((hd(e)=QUOTE)  - hd(tl(e», 

(hd(eHCOND)  -»  evcon(tl(e),a), 
apply(  hd(e),  evlis(tl(e),a),  a)),  1] 

A noteworthy  technique  for  working  in  LCF  was  just  used  but  the  following 
abstract  example  will  illustrate  it  better  since  it  has  less  irrelevant  detail;  we 
suppose  two  functions  (L,M)  satisfy  the  equations; 

L « P(L,M)  and  M n Q(L,M) 

The  MUTUAL  least  fixed  points  for  L and  M are  given  by  the  definitions: 
L ^ [^F.  P(F,[/iG.Q(F,G)])]  and  M 3 [mg,  Q(L,G)] . 

Similarly,  supposing  three  functions  <L,M,N)  satisfy  the  equations: 

L « P(L,M,N)  M n Q(L,M,N)  N 3 R(L,M,N) 
the  MUTUAL  least  fixed  points  for  L,M,N  are  given  by  the  quite  lengthy  definitions: 
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**  AXIOM  PL  10: 


eval  - [pB.fxe  a. 
islist(a)-» 

(atom(e)  -♦  tl( asGOc<e,a)), 
hdte)--QUOTE  - hdWK*», 
hd(e)=C0ND  -* 

[pG.[xc  a.  (B(hd(hd(c)),a)=T)  -»  B(hd(tl(hd(c))),a), 
(B(hd(hd(c)),a)=F)  ->  G(tl(c),a),l]](tl(e),a), 


{pG.{xfn  x a.  tKx)-* 

(fn=CAR)  -*  hd(hd(x)), 

(fn=CDR)  tl(hd<x>), 

(fn=C0NS)  ->  hd<x)-hd<tl(x)), 

(fn^ATOM)  -*  atom(hd(x))  -»  T,  F, 

{tn^Eg;  -*  [Xx  y .al  om(  x)  - at  otti(  y ) -*(  * -/) , 
l,l](hd(x)|hd(tl(x)))-»  T,F, 
atom(fn)  -*  G(B(fn,a),x,a), 

(hd(fnHLAMBDA)  - B<hd<tl<tl< fn))),  pairlis(hd(tl(fn)),x,a)), 
(hd(fn)=LABEL)  - G(hd<tl<tl< fn))),x, 

((hd(tl(fn))»hd(tl(tl(fn))))'a)),l,l,i]] 


<hd(e), 

[pG.[xm  a.  nuH(m)-*NlL, 

B<  hd<  m)  ,a)  *G<  1 1(  m)  ,a)  ]]( 1 1(  e)  ,a) , 

a)),  1] 


Figure  6.2  - The  Definition  of  'Eval’. 
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M « \nG.  Q(L,G,[mH.R(L,G,H)]] 

N - [nH.  R(L,M,H)] 


6.3.  Discussion  of  the  Axioms! 


6.3.1.  A Different  !evcon\ 

Because  we  have  modelled  the  above  definitions  on  McCarthy’s  interpreter, 
an  actual  difference  in  the  semantics  is  accented  - a difference  in  the  actions  of  the 
two  functions  'evcon\  That  there  is  discrepancy  is  illustrated  by  the  example: 


eval(  (COND  ( (QUOTE  X)  (QUOTE  X)  ) 

( (QUOTE  T)  (QUOTE  T)  ) ),  NIL) 


In  our  semantics  this  term  is  1 whereas  the  old  interpreter  will  yield  the 
answer  T.  Wc  feel  justified  in  making  this  small  change  since  it  seems  that  the 
action  of  McCarthy’s  interpreter  (in  this  case)  is  at  variance  with  the  natural 
language  description  of  Pure  LISP.  We  quote  from  [12]  the  definition  of  conditional 
expression: 


" A conditional  expression  has  the  following  form: 
[P|-‘e,;  P2->e2;...;pn-»en], 

where  each  p,  is  an  expression  whose  value  may  be 
truth  or  falsity,  and  each  e,  is  an  expression.  " 
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6.3.2.  'lisp’  is  not  'evalquote’. 


[12]  presents  the  top  level  of  the  Pure  LISP  Interpreter  to  be  the 


'evalquote’  function  which  corresponds  to 


[xfn  x.  apply(fn,x,NIL)] . 


We  could  also  have  defined  'lisp’  to  be  that  term,  but  have  chosen  instead 


to  follow  the  example  of  the  usual  LISP  systems  which  use  'eval’  as  the  'top  level’. 


6.3.3.  Strictness  of  'eval’  and  'apply’. 


Next  note  that  the  definitions  of  'eval’  and  'apply’  have  the  following 


structure: 


eval  - [/iF.[xe  a.  islist(a)->(atom(eM..), (..)),  1]] 
apply  - [jiG.[xfn  x a.  3(xHslist(a)-k 
((fn=CARM..)IU)Ii,i]]  • 


The  main  point  of  the  'islist(a)’  and  '3(x)’  conditions  is  to  ensure  that  each 


of  these  two  functions  is  strict  in  each  argument  position.  Of  course,  '3(a)’  would 


have  guaranteed  strictness  equally  well  as  'islist(a)’  but  the  latter  was  chosen  for 


imagined  technical  convenience:  we  are  only  interested  in  the  function  when  the  last 


argument  is  an  association  list  so  it  might  as  well  be  undefined  if  that  argument  is 
not  even  a list.  In  retrospect  it  would  be  preferable  to  replace  "islist(a)’  by  '3(a)’  in 
both  definitions  since  some  theorems  are  more  compactly  stated  and  many  proofs 


become  easier. 


wwsraspww  •©‘sr, 


Actually,  strictness  in  the  last  argument  position  for  'apply’  is  not  essential 
but  strictness  in  the  second  argument  positions  of  both  'eval’  and  'apply’  is  required 
to  prevent  counter-intuitive  results,  The  following  examples  illustrate  this  fact: 
i)  lispt  (LAMBDA  (X)  (QUOTE  T))*NIL  ) . 

This  term  computes  to 

applyt  (LAMBDA  (X)  (QUOTE  T)), NIL, NIL) 
and  then  to 

evalt  (QUOTE  T),l)  . 

Depending  on  whether  we  have  the  'isiist(a)’  condition  in  the 
definition  of  'eval’  or  not  this  further  computes  to  1 or  T 
respectively.  Now  1 is  the  appropriate  answer  since  a 
disaster  occured  during  the  computation.  We  would  expect 
mechanical  computation  ( as  with  an  interpreter  ) of  this 
example  to  FAIL  at  the  point  where  'hd(NIL)’  is  required. 


ii) 


lispt  ((LAMBDA  NIL  (QUOTE  T)) 

( (LABEL  N (LAMBDA  NIL  (N)))  NIL)) ) 


Noting  that 

evalt  ((LABEL  N (LAMBDA  NIL  (N)))  NIL), NIL)  = 1 
This  term  computes  to 

applyt  (LAMBDA  NIL  (QUOTE  T)),  1,  NIL)  . 
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Then,  depending  on  whether  the  '8(x)’  condition  is  in  the 
definition  of  'apply’  or  not,  we  get,  as  the  answer,  either  1 or 
T . Again  the  latter  answer  is  counter-intuitive  since 
mechanical  interpretation  (usirg  ycC^rthy’s  model)  of 
eval(  ((LABEL  N (LAMBDA  NIL  (N)))  NIL), NIL) 
would  go  on  forever. 


6.,3.4.  Total  Formality. 

Since  the  meaning  of  Pure  LISP  is  embodied  in  the  function  'lisp’  in  the 
axiomatic  setting  we  have  provided,  we  have  succeeded  in  giving  a completely 
formal  specification  of  the  language.  Contrast  this  with  the  method  of  [12]  where 
Pure  LISP  is  first  described  in  plain  language  and  then  this  definition  is  'tightened  up’ 
by  the  presentation  of  an  interpreter.  Note  that  this  interpreter  is  not  a definition  of 
the  language  since  it  is  only  meaningful  in  the  context  of  the  accompanying  natural 
language  description. 


6.4.  Theorems  of  Pure  LISP: 


Having  the  definitions  Pr  'lisp’  and  the  auxiliary  functions  is  barely  half  the 
job  of  constructing  a 'theory  of  Pure  LISP’  that  can  be  applied  to  proofs  of 
correctness  of  programs.  We  now  need  to  develop  a body  of  theorems  which  we 
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can  expect  will  facilitate  such  applications.  Presented  in  this  section  is  such  a 


collection  of  lemmas  giving  properties  of  the  functions  'eval’  etc.  and  giving  the 

results  of  these  functions  in  special  cases.  Most  of  the  theorem*  are  suitable  for 
inclusion  in  a SIMPSET. 

We  start  by  presenting  some  lemmas  for  the  functions  'eval’,  'evils’  and 
'pairlis'  These  functions  are  strict  in  almost  all  argument  positions.  Where 
appropriate  the  strictness  results  such  as  (■  Vx.evlisU.x)  s i were  proved 
although  we  do  not  list  them.  More  interesting  are  the  following: 

i)  I-  Vx  y a.  evcon(«QUOTE  T)  x)»y,a)  ^(y)-*eval(x,a),l 


ii) 


c'(X)  -T,  ci(Y)-T  h Vw  a.  evcon(  (w  X)»Y,  a) 

- (evaKw.aHTHevaKX.a), 
(eval(w,a)=F)-»evcon(Y,a),l 


iii) 


iv) 


f-  Ya.  evlis(NIL,a)  - NIL 

I-  Vx  a.  evlis((x),a)  3 (eval(x,a)) 

I-  Vx  y a.  evlis((x  y),a)  ^ (eval(x,a)  eval(y,a)) 
etc. 

I-  Vx  y a.  pairlis((x),(y),a)  - (x»y)°a 

I-  Vxl  x2  yl  y2  a.  pairlis(  (xl  x2),  (yl  y2),  a) 

= (xl-yl)  • ((x2»y2)  * a) 
etc. 


Building  on  these  results,  we  are  able  to  derive  more  easily  basic  lemmas 
describing  the  effects  of  'evaP  and  'apply’  on  come  common  constructs.  (Again  we  do 
not  concern  ourselves  with  strictness  results  but  just  report  on  their  existence.) 

We  start  with  three  special  cases  of  'eval’  on  expressions  which  do  not  involve 
function  calls: 
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b Vx  a.  eval{  COND*x,  a)  s evcon(x,a) 


b Vx  a.  eval(  (QUOTE  x),  a)  3 islist(a)->x,l 


atom(X)=T  b Vy  a.  eval(X,(X-y)«a)  = islist(a)-*y,JL 


atomfX^T,  X=X1=F 

b Vy  yl  a.  eval(X,(Xl»yl)'((X»y)»a)) 

= isiist(a)  -*  ci(yl)-»y,l,  1 


There  is  some  taste  involved  in  how  one  states  many  of  these  theorems. 


This  last  theorem,  for  instance,  could  have  been  written  as 


atom(X)*T,  X=X1^F,  islist(A)=T,  a(Yl)=-T 

b Vy.  eval(X,(Xl'Y!H(X'y)«A))  ■ y 


The  next  group  of  theorems  concerns  the  application  of  the  five  standard 


functions; 


b Vx  a.  apply(CAR,(x),a)  ~ islist(a)  -»  hd(x),  1 
b Vx  a.  apply  (ATOM, (x), a)  3 islist(a)-*  (atom(x)->T,F),  1 


and  similar  results  for  CDR,  CONS  and  EQ 


b Vx  a.  eval(  (CDR  x),  a)  ® tl(eval(x,a)) 
b Vx  y a,  eval((C0NS  x y),  a)  = eval(x,a)'eval(y,a) 


and  similar  results  for  CAR,  ATOM  and  EQ. 


Finally  there  are  theorems  (or  families  of  theorems)  for  the  cases  of  'eval’ 


and  ’apply’  which  involve  functions  which  are  given  explicitly  as  LABELed 


expressions  or  as  LAMBDA  expressions; 


b Vn  f x a.  apply((LAEEL  n f),x,a)  3 apply(f,x,(mf)°a) 


- . . rssjy , & 
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h Vn  f x a.  eval(((LABEL  n f)  x),a)  ••-  apply(i,eviis(x,a),(rvf)'a) 


I-  Vb  a.  apply((LAMBDA  NIL  b),NIL,a)  = eval(b.a) 

H Vx  y b a.  apply((LAMBDA  (x)  b),(y),a)  = eval(b,(x«y).a) 


etc.  for  higher  arities  of  the  function. 


xiv)  h Vb  a.  eval(((LAMBDA  NIL  b)),a)  = evalfb.a) 

}-  Vx  y b a.  eval(((LAMBDA  (x)  b)  y),a)  » eval(b,(*eval(y,a))-a) 


■ «£* 
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CHAPTER  7 

Applications  of  the  Theory  of  Pure  LISP 


We  shall  discuss  ir  this  brief  chapter  the  application  of  the  semantics  of 
Pure  LISP  (developed  in  Chapter  6)  to  the  correctness  of  several  simple  LISP 
functions.  The  purpose  of  working  these  examples  is  to  illustrate  some  simple 
techniques  that  may  help  in  converting  LISP  functions  to  the  the  LCF  functionals  that 
they  yield  via  interpretation.  The  three  functions  we  use  need  to  be  defined  and 
discussed  anyway  because  they  are  used  in  the  LISP  interpreter  that  we  discuss  in 
the  next  chapter.  The  functions  are 

i)  The  NULL  function  of  one  argument  X;  It  returns  T if  X is  NIL  else 

returns  F;  There  is  no  recursion  involved. 

ii)  The  EQUAL  function  of  two  arguments  X,Y;  It  returns  T if  X is  the 

same  individual  as  Y;  It  is  recursive  but  calls  no  other  recursive 
function  internally. 

iii)  An  ASSOC  function  of  two  arguments  X,A;  It  returns  the  first  pair  in 

list  A whose  head  is  X although  if  there  is  no  such  pair  it  gives 
NIL;  It  is  recursive  and  it  makes  a call  on  another  recursive 
function  ( EQUAL  ). 
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Before  we  discuss  the  examples  in  turn,  some  more  axioms  must  be  given 
(added  to  the  environment  axioms  of  Chapter  4 and  the  Pure  LISP  axioms  of  Chapter 
6).  We  must  say  that  EQUAL,  X,  A,  ASSOC  etc.  are  all  names  (of  functions  or 
parameters)  and  distinct  from  each  other  and  from  the  names  LAMBDA,  CAR  etc. 
Also  it  is  convenient  to  have  names  for  the  S-expressions  which  are  the  bodies  of 
the  functions  NULL,  EQUAL,  ASSOC.  So: 


**AXIOM  PL  1 


diset (ASSOC)  :•  discr(T)  a T, 
discr(EQUAL)  > discr(ASSOC)  s X, 
discr(NULL)  :>  discr( EQUAL)  a X, 
discr(A)  > discr(NULL)  a X, 
discr(X)  > discr(A)  = T, 
discr(Y)  > discr(X)  a X 


**AXI0M  PL  1 2: 

Snull  --  (LAMBDA  (X)  (COND 


ft 


\\ 


ATOM  X)  (EQ  X (QUOTE  NIL))) 


((QUOTE  T)  (QUOTE  F)))) 


** AXIOM  PL  13: 

Sequal  « (LABEL  EQUAL  SequalB), 
SequalB  * (LAMBDA  (X  Y)  fCOND 
((ATOM  X)  (COND 

((ATOM  Y)  (EQ  X Y)) 
((QUOTE  T)  (QUOTE  F)))) 
((ATOM  Y)  (QUOTE  F)) 

((EQUAL  (CAR  X)  (CAR  Y)) 
(EQUAL  (CDR  X)  (CDR  Y))) 
((QUOTE  T)  (QUOTE  F)))) 
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♦♦AXIOM  PL  14: 

Sassoe  a (LABEL  ASSOC  SassoeB), 

SassocB  = (LAMBDA  (X  A)  (COND 
((NULL  A)  (QUOTE  NIL)) 

((EQUAL  (CAR  (CAR  A))  X)  (CAR  A)) 
((QUOTE  T)  (ASSOC  X (CDR  A))))) 


7.1.  The  NULL  Function! 


The  correctness  of  the  NULL  function,  given  by  an  S-expression  above,  is 
succinctly  captured  in  the  theorem: 

F Ve.  licpf  (StujW  e) } * *jW$SvaKeW  -*  T,  F . 


However,  two  theorems  which  are  much  more  useful  are: 
F Ve  a.  apply(Snull,(e),a)  = islist(aMnull(e)-»T,F),l 


and 


F Ve  a.e vol< (Snull  e),a)  e null(eval(e,a))-»T,F  . 

Actually,  these  theorems  cover  only  the  important  and  usual  case  where 
the  function  is  applied  to  precisely  one  argument.  A more  general  result  is: 

F Vx  a.  apply(Snull,x,a)  s islist(a)-»(null(hd(x))-»T,F),l  . 

In  fact,  all  of  these  theorems  are  trivial  to  prove  in  the  LCF  system  and  it 
suffices  to  consider  just  the  second  of  the  four.  The  appropriate  attack  is  with 
ABSTRaction  followed  by  CASES  on  ’islist(a)’  and  '£i(e)\  The  only  subcase  with  any 
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interest  is  the  one  in  which  we  have  'islist(a)=T,  afe)*!’.  We  use  SIMPLification  on 
this  and  the  subgoal  we  get  is 

atom(e)  -*  (atom(eMe=NIL),iHT,F, 

atom(e)  ->  1,F  s null(e)-*T,F  . 

This  subgoal  happens  to  be  easily  provable  by  CASES  on  'atom(e)’  but  the 
important  thing  about  it  is  that  it  contains  no  mention  of  'eval*,  'apply*  etc.;  It  is 
simply  a proposition  in  LCF  involving  the  equality  of  two  terms  which  denote 
individuals  and  proving  this  subgoal  has  nothing  whatever  to  do  with  the  semantics 
of  LISP.  The  number  of  substitutions  which  were  ordered  by  the  simplification 
routine  is  quite  large  and  so  we  see  we  are  reaping  benefits  from  having  a SIMPSET 
which  was  rich  in  special  cases  of  the  LISP  primitives. 

The  NULL  function  is  a good  example  of  the  simple  (but  common)  case  of  a 
function  F which  is  just  a LAMBDA  term  and  which  contains  no  nested  LABEL 
constructs  and  uses  no  unbound  variables.  As  a statement  of  correctness  of  F,  we 
will  be  seeking  to  prove  a theorem  that  looks  like 

Va  x y....  apply(F,(x  y ...),a)  s islist(a)->G(x,y,...),i 

It  is  proposed  that  in  proving  such  a result  one  attacks  with  ABSTRaction, 
does  CASES  on  islist(a)  and  CASEo  on  the  definedness  of  each  of  the  arguments 

<x.y.->-  lf  we  are  lucky  a|l  but  one  of  the  subgoals  are  trivial  and  the  nontrivial  one 
SIMPLifies  to  a subgoal  which  is  quite  free  of  'eval’,  'apply*  etc. 


70 


- 


<'V-' 

ill 


yj 

ife 


vy; 


7.2.  The  EQ.UAL  Function: 


EQUAL  is  an  example  of  a function  which  is  recursive  but  does  not  call  any 
other  recursive  function  internally  <i.e.  it  does  not  contain  any  LABEL  constructs). 
Again  the  statement  of  correctness  is  simple  and  comes  in  a variety  of  forms  such 
as: 

Vx  y a.  apply(Sequal,(x  y),a)  a islist(a)  •+  (x=y)-»T,F,  1 , 

Recalling  that  Sequal  and  SequalB  are  the  S-expressions  that  are  the  whole 
LISP  function  and  its  body  respectively,  we  tackle  the  above  theorem  via  the  lemma: 


Vx  y a.  ci(x)*  a(y)=>  assoc(EQUAL,a)=(EQUAL’SequalB)* 

applyf SequalB,  (x  y),  a)  a (*=y)-»T,F  . 


This  lemma  is  appropriately  attacked  by  induction  on  the  structure,  oi  either 
of  the  arguments  of  EQUAL  since  the  recursion  of  this  function  takes  both  apart. 
More  specifically  we  do  induction  on  some  occurences  of  V using  an  equation  that 
was  introduced  as  an  axiom  in  the  Theory  of  Lists  in  Chapter  4 
a a [>G.[\x.  atom(x)->T,G(hd(x))-*G(tl(x)),l]] 

The  base  case  is  trivial  and  the  other  case  reduces  to  a subgoal  where  we 

have 


G(hd(x))-T,  G(tl(x)hTP  a(y)*T, 
a$soc(EQUAL,aHEQUAL-SequalB), 

Vx  y a.G(x)*  ci(y)=>  assoc(EQUAL,a)=(EQUAL»SequalB)* 
apply(SequalB,  (x  y),  a)  a (x=y)-*T,F 
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and  we  must  prove 

apply* SequalB,  (x  y),  a)  = <x=y)-*T,F  . 

The  next  attack  on  the  problem  is  by  using  the  definition  of  SequalB  and 
the  SIMPSET  which  is  primed  with  the  nice  lemmas  that  we  described  in  Chapter  6. 
Simplification  does  not  simplify  it  to  something  which  is  free  of  'apply’  and  'evaP;  the 
subterms  which  are  the  recursive  calls  on  EQUAL  are  almost  intact.  However,  by 
doing  the  CASES  arguments  that  suggest  themselves  and  applying  the  induction 
hypothesis  we  complete  the  proof  of  the  lemma  and  then  the  proof  nf  the  main 
result  for  EQUAL  quickly  follows. 

The  important  technique  illustrated  is  that  when  one  has  a LISP  function  F 
which  is  an  S-expression  (LABEL  F 8)  (where  B is  the  body),  and  we  want  to 
establish  a theorem  that  looks  like 

Vx  y ....  apply(F,(x  y ...),a)  a islist(a)-*G(x,y,...),l 
then  we  try  to  prove  a lemma  that  looks  like 

Vx  y ...  a.  £i(x)*  8(y)=>  assoc(F,a)=(F»B)* 

apply(B,(x  y ...),a)  = G(x,y,...) 

and  we  attack  the  problem  using  an  induction  that  reflects  the  computation  that 
function  G performs;  perhaps  we  use  the  definition  of  G and  perhaps  we  use 
induction  on  the  structure  of  an  argument  of  G that  it  tears  apart. 
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7.3.  The  ASSOC  Function: 

We  refer  back  to  the  start  of  the  chapter  for  the  S-expression  form  of 
ASSOC  (the  S-expression  is  named  Sassoc).  We  also  give  here  a corresponding  Pure 
LISP  function  in  M-notation 

assoc[x;a]  = [null[a]->NIL; 

equal[car[a];x]->car[x]; 

T->assoc[xjcdr[a]]] 

As  shown  by  its  definition,  the  ASSOC  function  chosen  is  recursive  and  also 
makes  internal  use  of  another  recursive  function;  that  is,  it  has  a nested  LABEL 
construct.  The  correctness  results  for  ASSOC  are  typified  by: 

Vx  y a.  apply(Sassoc,(x  y),a)  a islist(a)-*  assoc(x,y),  1 . 

The  recursion  aspect  is  handled  in  the  same  manner  as  it  was  in  the  proof 
of  correctness  of  EQUAL;  we  prove  the  lemma 

Vx  y a.  <D(x)=>  d(y)=>  assoc(ASSOC,aMA$SOC»SassocB)* 

apply(Sassoc,(x  y),a)  ■ assoc(x,y) 

doing  it  by  induction  on  the  second  argument  of  ASSOC.  The  internal  call  on  the 

recursive  function  EQUAL  is  no  problem  because  we  already  have  the  result  (last 

section): 

Vx  y a.  apply(Sequal,(x  y),a)  = islist(aMx=y)->T,F,l 
which  is  great  as  a simplification  rule, 
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In  general  when  a function  contains  a call  on  a recursive  function,  we  prove 
a correctness  result  for  the  sub-function  first. 


7.4.  Remarks! 


The  extraction  of  meaning  functions  for  LISP  functions  from  their  S- 
exprossion  forms,  provided  mutual  recursion  is  not  involved,  seems  rather  straight- 
forward and  the  prognosis  for  automation  of  the  process  is  good.  The  simplification 
mechanism  already  does  a huge  amount  of  the  work  and  it  is  the  author’s  belief  that 
more  effort  spent  on  the  scope  of  the  Theory  of  Pure  LISP  and  further  development 
of  the  LCF  system  would  make  the  proofs  even  easier  to  generate  and  comprehend. 

Although  we  have  not  worked  any  simple  examples  of  correctness  of 
mutually  recursive  functions  the  LISP  Interpreter  proof  in  the  next  chapter  involves 
several  case  of  mutual  recursion  (and  is  rather  complicated). 
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CHAPTER  8 

The  Correctness  of  an  Interpreter 


When  McCarthy  presented  an  interpreter  for  Pure  USP  he  did  so  in 
'm-expression’  notation  but  the  report  also  contained  an  algorithm  for  translating 
m-expressions  to  S-expressions.  Following  his  prescription  (and  making  the  change 
to  'evcon’  recommended  in  Chapter  6),  we  present  in  Figure  8.1  (next  two  pages) 
the  various  functions  (that  constitute  this  interpreter)  as  S-expressions;  we  also 
give  names  to  these  terms  so  they  are  given  as  an  fsxtra  axiom  (PL15).  Note  that 
we  still  need  all  the  axioms  of  Chapter  7 (as  well  as  those  for  Pure  LISP  and  the 
environment)  since  EVAL,  APPLY  etc.  make  use  of  NULL,  EQUAL  and  ASSOC. 

Note  that  these  functions  are  oriented  towards  EVAL  being  the  function 
called  at  the  top  level.  In  Pure  LISP  one  does  not  declare  the  various  functions  one 
uses  but  writes  them  down  in  every  place  they  are  called  except  inside  of 
themselves.  Hence,  as  PL15  is  written,  Sapply  must  just  be  considered  a 
subexpression  of  Seval;  'lisp((Sapply  x))’  will  be  undefined  for  all  S-expressions  x 
that  require  a call  of  EVAL  Similar  remarks  hold  for  Sevlis  and  Sevcon.  If  it  was 
desired  that  APPLY  be  the  main  function  (as  in  the  'evalquote’  model  of  the  top 
level)  then  one  toufd  change  (in  PLI S>  0*  'EVAL’o  in  ’SapplyB’  to  'Seval’  and  (he 
'Sapply’  in  'Seval’  to  'APPLY’  . 
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★★AXIOM  PL1 5: 


Seval  (LABEL  EVAL  SttvalB) 

SevalB  - (LAMBDA  (E  A)  (COND 

((ATOM  E)  (CDR  (Sassoc  E A))) 

((ATOM  (CAR  E))  (COND 
((EQ  (CAR  E)  (QUOTE  QUOTE))  (CAR  (CDR  E))) 

((EQ  (CAR  E)  (QUOTE  COND))  (Sevcon  (CDR  E)  A)) 
((QUOTE  T)  (Sappty  (CAR  E)  (Sevlis  (CDR  E)  A)  A)))) 
(( QUOTE  T)  (Sappty  (CAR  E)  M (CuR  E)  A)  A)))) 


Sapply  .:  (LABEL  APPLY  SapplyB) 

SapplyB  - (LAMBDA  (FN  X A)  (COND 
((ATOM  FN)  (COND 

((EQ  FN  (QUOTE  CAR))  (CAR  (CAR  X))) 

((EQ  FN  (QUOTE  CDR))  (CDR  (CAR  X))) 

((EQ  FN  (QUOTE  CONS)) 

(CONS  (CAR  X)  (CAR  (CDR  X)))) 

((EQ  FN  (QUOTE  ATOM))  (ATOM  (CAR  X))) 

((EQ  FN  (QUOTE  EQ)) 

(EQ  (CAR  X)  (CAR  (CDR  X)))) 

((QUOTE  T)  (APPLY  (EVAL  FN  A)  X A)))) 

((EQ  (CAR  FN)  (QUOTE  LAMBDA)) 

(EVAL  (CAR  (CDR  (CDR  FN))) 

(Spairfis  (CAR  (CDR  FN))  X A))) 

((EQ  (CAR  FN)  (QUOTE  LABEL)) 

(APPLY  (CAR  (CDR  (CDR  FN)))  X 
(CONS  (CONS  (CAR  (CDR  FN)) 

(CAR  (CDR  (CDR  FN))))  A))))) 


Figure  8.1a  - S-expression  Form  of  the  Interpreter. 
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Sevcon  - (LABEL  EVCON  SevconB) 

SevconB  - (LAMBDA  (C  A)  (COND 
((EVAL  (CAR  (CAR  C))  A) 

(EVAL  (CAR  (CDR  (CAR  C)))  A)) 
((EQ  (EVAL  (CAR  (CAR  C))  A)  (QUOTE  F}) 
(EVCON  (CDR  C)  A)))) 


Sevlis  = (LABEL  EVLIS  SevlisB) 
SevlisB  a (LAMBDA  (M  A)  (COND 
((Snull  M)  (QUOTE  NIL}} 


((QUOTE  T)  (CONS  (EVAL  (CAR  M}  A} 


(EVLIS  (CDR  M)  A)}))} 


Spairlis  u (LABEL  PAIRLIS  SpairlisB) 

SpairlisB  * (LAMBDA  (X  Y A}  (COND 
•'('Snull  X'  A' 

((QUOTE  T) '(CONS  (CONS  (CAR  X)  (CAR  Y}) 
(PAIRLIS  (CDR  X}  (CDR  YJ  A}}))} 


Figure  8.1b  - S-expression  Form  of  the  Interpreter  (ctd). 
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Before  we  discuss  the  correctness  of  these  functions  we  must  give  yet  one 
more  axiom  to  introduce  the  various  function  names  and  formal  parameter  names  for 
the  functions: 

PAIRLIS,  APPLY,  ASSOC,  EVCON,  EVLIS,  EVAL,  C,  Et  M * 

We  do  this  in  the  same  way  as  we  introduced  particular  names  in  Chapters  2 and  3; 
that  is: 

** AXIOM  PL  16: 


discr(PAIRLIS)  > discr(Y)  = T, 
discr< APPLY)  > discr(PAIRLIS)  - T, 
etc. 


8.1.  Meaning  of  PAIRLIS: 


The  PAIRLIS  function  is  similar  in  structure  to  the  ASSOC  function  (see 
previous  chapter)  in  that  it  is  recursive  and  has  an  internal  call  to  another  function. 
It  is  not  involved  in  the  mutual  recursion  that  is  exhibited  by  EVAL  etc.  so  we  are 
able  to  give  a meaning  function  for  it  just  as  we  did  with  ASSOC.  It  should  come  as 
no  surprise  to  learn  that  the  function  induced  by  PAIRLIS  under  interpretation  is  the 
pairlr/  function  which  is  part  of  the  axioms  for  Pure  LISP. 

A convenient  statement  of  correctness  for  the  PAIRLIS  function  is  the 
following: 


Vx  y a al.  apply(Spairlis,  (x  y a),  al) 

3 islistfalH  c'(y)-»  pairlis(x,y,a),  1,  ’ . 


78 


I 


m 


m 

a: 


I 

| 

1 

f « 


' 


z 


% 


Care  should  be  used  to  avoid  confusion  (here  and  in  the  rest  of  the 
chapter)  when  two  A-lists  appear  in  a theorem;  one  will  be  used  in  the  LCF 
interpretation  of  the  interpreter  functions  (such  as  EVAL  and  EVLIS)  and  the  other  is 
a parameter  of  these  functions.  In  the  case  we  have  here,  PAIRUS  needs  an  A-list 
as  a parameter  and  'apply’  need  an  A-list  to  interpret  the  Interpreter  function 
PAiRUS. 


8.2.  Important  Lemmas: 


The  big  problem  with  EVAL,  APPLY,  EVCON  and  EVLIS  is  that  they  are 
mutually  recursive;  each  of  APPLY,  EVCON  and  EVLIS  call  tVAL  and  EVAL  calls  the 
other  three.  Although  it  is  rather  comolicated  as  an  example,  it  is  hoped  that  the 
proof  of  correctness  of  EVAL  will  give  some  insight  to  the  rather  common 
phenomenon  of  mutual  recursion. 

We  now  present  the  main  correctness  theorem  for  the  S-expression  form 
of  the  Pure  LISP  interpreter: 

Ve  a al.  apply(Seval,(e  a),al)  » islist(al)-*  eval(e,a),JL 


and  we  will  also  seek  the  auxiliary  results: 


**1 

**2 


assoc(EVAL,alMEVAL»SevalB) 

H Ve  a.  apply(SevalB,(e  a),al)  a eval(e,a) 


assoc(EVAL,al)s:(EVAL'SevalB) 

H Vc  a.  apply($evcon,(c  a),al)  ■ evcon(c.a) 
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**3  assoc(EVAL,al)-(EVAL'SevalB) 

f ■ a-  apply(Sevtis,(m  a),al)  ^ evlis(m,a) 

**4  assoc(EVAL,al)-(EVAL’SevalB) 

I-  Vfn  x a . apply(Sapply,(fn  x a),al)  s appiy(fn,x,a) 

(Note  that  by  a property  of  'assoc’  we  can  deduce  from  'ti(assoc(X,al))sT’ 
the  *;ad  'islist(al)~T  ). 

Without  seeking  prior  motivation,  consider  just  the  'evlis’  function  (because 

it  is  the  simplest)  and  the  following  proposition: 

**5  islist(a)  T, 

assoc(EVUS,al):  (EVLIS-SevlisB), 
assoc(EVAL,a!)  (EVAL-'SevalB), 
f-  Vm.  apply(Sevlis,  (m  a),al) 
n [xall.  null(m)  - NIL, 

apply(SevalB,(hd(m)  a),all)  • apply(SevlisB,(tl(m)  a), all)] 
(M<'mM(A*a)»al)  . 

One  cannot  help  but  notice  a strong  resemblance  between  the  consequent 
of  this  equation  and  the  recursive  equation  that  'evils’  is  the  least  fixed  point  of: 
evlis  » [\m  a.  null(m)  -»  NIL,eval(hd(m),a)  • evlis(tl(m)  a)  ] 

This  lemma  (**5)  is  aptly  characterised  as  a statement  of  'relative 
correctness’  of  EVLIS  since  if  the  function  EVAL  were  correct  (i.e.  obeys  result  **1) 
then  a simple  induction  will  transform  it  into  the  correctness  statement  **3. 

The  proof  of  the  lemma  (**5)  is  conceptually  very  simple  involving  only  the 
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multiple  application  of  the  definition  of  'apply*  (and  the  other  interpreting  functions) 


and  is  generable  interactively  very  easily:  it  involves  less  than  30  steps  (mainly 


CASES  and  SIMPUfications)  although  there  are  hundreds  of  behind-the-scenes 


substitutions  performed  by  the  simplification  algorithm. 


Similar  lemmas  are  provable  for  the  ether  3 functions  (eval,  apply  and 


evcon)  and  we  state  all  four  results  as  Figure  8.2  (next  two  pages).  These 


theorems  should  be  compared  closely  with  those  of  Figure  8.3  to  note  the 


correspondence  of  structure.  The  four  proofs  are  almost  mechanical  since  they 


involve  primarily  obvious  CASES  arguments  and  SIMPUfications.  The  proof  of  the 


lemma  involving  APPLY  is  the  longest  being  about  60  steps. 


8.3.  Informal  Proof  of  Interpreter  Correctness: 


Now,  speaking  quite  informally,  and  omitting  any  discussion  of  the 


definedness  (or  listness)  of  arguments  of  EVAL,  APPLY  etc.  it  is  readily  seen  that 


these  four  lemmas  can  serve  as  a basis  for  computing  values  of  the  function 


[\e  a al.  apply(Seval,(e  a),al)] 


just  as  the  equations  of  Fig  8.3  can  serve  as  a basis  for  computing  values  of  'evaP. 


For  example, 


eval((AT0M  (QUOTE  X)),  NIL) 
computes  through 

apply(AT0M,evlis(((QU0TE  X)), NIL), NIL) 


islist(a)  - T |- 

Vm  al  . assoc(EVUS,alME\/LIS’Sevlis3)$ 

assoc<EVAL,al)=(EVAL«SevalB)  * 
apply(SevlisB,nWa<NIL),al)  = null(m)-»ML, 
(apply(SevalB,hd(m)*(a«IMIL),(M«m)o((A*a)*al)) 
•apply(SevlisB,tl(m)*(a*NIL),(M*m)‘((A*a)*al))) 


islist(a)  - T H 

Vfn  x al  . as$oc( APPLY, al)=(APPLY»$applyB)  * 
assoc(EVAL,al)=(EVAL«SevalB)  *> 
apply(SapplyB,fn-(x*(a»NIL)),al)  s (fn=CAR)->hd(hd(x))t 
((fn-CDRMKhd(x)), 

((fn-CONS)-(hd(x)-hd(tl(x))), 

((fn-ATOM)-(atorn(hd(x))-*r,F), 

((fn-EQM[xx  y .atom(x)-(atom(y)-*(x=y),l),l] 

(hd(x),hd(tl(x)))-*T,F)f 

( at  om(  f n)-apply(  SapplyB,apply(  SevalB,f  n-  ( a*NIL), 
(FNfn)'{(X»x)’{(A''a)’al)))’(x-(aNIL)), 

(F[WnM(X«xM(A«a)eal))}, 

((hd(fn)=LAMBDA)-*apply(SevaiB, 

hd(tl(tl(fn)))»(pairlis(hd(tl(fn)),x,a)<>NIL), 

(FN‘’fn)"((X''x)»((A«a)'al))), 

((hd(fn)=LABEL)-*apply(SapplyB, 

hd(tl(tl(fn)))«(x’(((hd(tl{fn))'hd(tl(tl(fn))))*a)«NIL))l 

(FN«fn)o((X»x)'((A«a)ral))),l))))))) 


Figure  8.2a  - Some  Lemmas  about  SevlisB  and  SappiyB. 
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islist(a)  n T F 

Vc  al  . assoc(EVCON,al)=(EVCON«SevconB)  * 
assoc(EVAL,al)=(E\/AL‘Seva[B)  » 
apply(SevconB,C'(a«NIL),al)  = 

(apply(SevalB,hd(hd(c)Ha»NIL),(C«cM(A*a)*al))=T)-> 

apply(SevalB,hd(tl(hd(c)))«(a»NIL),(C‘c)*((A*a)‘al)), 

((apply(SevalB,hd(hd(c))*(a»NIL),(C*c)*((A‘a)*al))>=F)-* 

apply(SevconB,tl(c)‘(a*NIL),(C*c)*((A‘a)*al)),l) 


islist(a)  « T h 

Vx  al.  assoc(EVAL,al)=(EVAL“SevalB)  * 
apply(SevalB,X"(a’NIL),al)  ® (aton^xMKassoc^a)), 
((hd(x)=QUOTE)-hd(tl(x)), 

( ( hd(  x)  =CONDHapply(Se  vconB.t  l(  x)«(  a-NIL>, 

(EVCON!'SevconBM(E,'x)«((A'a),al))), 

apply(SapplyB,hd(x)»(apply(SevlisB,tl(x)'(a<'NIL), 

(EVUS'SevliGB)K(E-x).((A.a)-al)))-(a»NIL)), 

(APPLV«SapplyB)*((E'x)«((A',a)»al)))))),l 


h eval  [Xe  a. 
islist(a)-* 

(atom(e)  -*  tl(assoc<e,a)>, 
hd(e)=QUOTE  hd<tl(e)), 
hd(ebC0NQ  ■*  evcon{tl(e),a), 
apply(hd(e),  evlis(tl(e),a),  a)),  1] 

h evcon  = [xc  a.  (eval(hd(hd(c)),a)=T)  ->  eval(hd(tl(hd(c))),a), 
(eval(hd(hd(c)),a)=F)  -*  evcon(tl(c),a)  , i] 

apply  [xfn  x a.  ri(x)-*  islist(a)** 

(fn-CAR)  hd(hd(x)), 

(fn-  CDR)  - tl<hd<x», 

(fn-CONS)  - hd{x)*hd(tl(x)>, 

(fn-ATOM)  - atom(hd(x))  - T,  F, 

(fn^EQ)  -*  [xx  y.  atom(x)-‘atom(y)-‘(x=y),  1,  l] 
<hd(x),hd(tl(x)»->  T,  F, 
atom(fn)  -»  apply(eval{fn,a),x,a), 

(hd(fn) -LAMBDA)  - eval<hd(tl<tl<fn)», 

pai  r I i s(  hd(  1 1 < f n>  ),x,  a) ) , 
(hd(fn)-LABEL)  -*  apply(hd(tl{tl(fn))),  x, 

«hd(tl<fn»-hd(tl(tl(fn»»-a», 

1, 1,  1 ] 

evlis  - [xm  a.  null(mHNIL,  eval(hd(m),a)  » evlis(tl(m),a)] 


Figure  8.3  - Some  Lemmas  about  eval,  apply,  evlis  & evcon. 
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and 

and 

to 


apply!  ATOM, <eval!(QUOTE  X), NIL)), NIL) 
apply(ATOM,(X),NIL) 

T . 


Similarly, 


apply! SevalB, ((ATOM  (QUOTE  X))  NIL),  NIL) 
computes  through 

apply!SapplyB,(ATOM 

apply! SevlisB, (((QUOTE  X))  NIL), all)  NIL), all) 
and 

apply(SapplyB,(ATOM 

(apply(SevalB, ((QUOTE  X)  NIL),al2))  NIL), all) 


and 

to 


apply!SapplyB,(ATOM  (X)  NIL),AL1) 
T . 


In  all  such  examples,  the  computation  terminates  when  there  is  no 
applicable  lemma;  this  will  be  just  when  there  is  no  more  instances  of  the 
interpreting  functions  ( apply  etc.)  and  if  the  computation  does  not  terminate  then 
the  result  will  be  1. 

It  should  be  apparent  that  if  we  do  the  computations  for  'evaKe.a)’  and 
'apply(SevalB,(e  a),al)’  then  because  of  the  structural  similarity  between  the  two 
sets  of  computation  rules,  those  two  computations  will  proceed  in  parallel  just  as 
they  did  in  the  above  example.  Moreover,  if  sne  of  these  computations  terminates 
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with  a certain  result  then  so  will  the  other  and  if  one  never  halts  then  neither  will 


the  other.  That  completes  the  informal  proof. 


8.4.  Interpreter  Correctness  in  LCPt 


The  above  informal  proof  suggests  an  attack  on  the  desired  main  results 


(**1  to  *+4)  using  the  results  of  Figure  8.2  and  computation  induction.  It  is 


appr  opriate  to  do  induction  on  the  definition  of  'eval’  but  we  notice  that  in  terms  of 


recursion  on  the  computation  of  'eval’  {and  'apply’  etc.)  the  left  hand  sides  of  the 


desired  results  compute  much  slower  than  the  right  hand  sides.  This  is  because  the 


interpretation  of  each  expression  is  done  directly  on  the  right  hand  side  but 


indirectly  (via  interpretation  of  EVAL,  APPLY,  EVLIS  or  EVCON)  on  the  left.  Thus  in 


doing  the  proof  we  are  forced  to  break  each  of  the  four  equivalences  into  two 


'inequivalences’: 


0S5oc(EVAL,AL)-(EVAL'SevalB) 

h Yx  a.  apply(SevalB,  (x  a),  AL)  s eval(x,a)  , 


assoc(EVAL,AL)  -(EVAL-SevalB) 

H Vx  a.  eval(x.a)  e apply(SevalB,  (x  a),  AL)  , 


assoc(EVAL,AL)  “(EVAL-SevalB) 

h Vc  a.  apply(Sevcon,  (c  a),  AL)  e evcon(c,a) 


! 


?; 


8.5.  Partial  Correctness! 


We  first  report  on  the  proof  of  the  inequality 


**6 


h Vx  a al.  assoc(EVAL,aI)=(EVAL'SevalB)» 

eval(x,a)  s apply(SevalB,  (x  a),  al) 


or,  using  the  predicate  Q=[\al.assoc(EVAL,al)=(EVAL»SevalB)], 

h Vx  a al.  Q(aD*  eval(x,a)  ^ apply(SevalB,(x  a),al)  . 


We  consider  this  proof  in  greater  detail  than  any  previous  one  because  it  is 
quite  complex  involving  several  nested  inductions.  The  outermost  induction  uses  the 
definition  of  ’eval’  and  the  inner  ones  correspond  to  the  definitions  of  ’apply’,  ’evils’ 
and  'evcon’. 

First  we  rewrite  the  definition  of  ’eval’  from  Fig  6.1  in  the  form 
'eval  : [/iB.P(B)]’  thus  defining  functional  'P’  which  is  free  of  B.  Then  we 
attack  the  goal  with  an  induction  that  uses  this  equation,  to  give  the  subgoals: 


i)  Vx  a al.  Q(al)=>  l(x,a)  s apply(SevalB,(x  a),al)  , 


ii)  Vx  a al.  Q(al)*  B(x,a)  s apply(SevalB,(x  a),al) 

h Vx  a al.  Q(al)=>  P(B,x,a)  s apply(SevalB,(x  a),al)  . 


Now  subgoal  (i)  is  trivial  by  SIMPLification.  We  attack  the  second  by 
ASSUMing  the  antecedent,  doing  PREFix  removal  in  the  consequent,  CASES  on 
Tatom(x)’  and  SIMPLification.  We  therefore  have  an  induction  hypothesis  assumed 
and  one  (complex)  subgoal  corresponding  to  the  interesting  case  where 
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' islist(a)  T, 

assoc(EVAL,alMEVAL-SevaIB), 
atorn(x)~F  ’ . 


We  further  attack  this  subgoal  by  CASES  on  'hd(x)=QUOTEJ  and  CASES  on 
‘hd(x)-COND’  and  by  using  some  monotonicity  theorems  we  get  four  subgoals  which 
are  shown  in  Figure  8,4  (next  page), 

The  key  to  proving  each  of  these  is  an  initial  induction;  in  the  last  we  use 
the  structure  of  the  first  argument  of  EVLIS;  in  the  first  three  we  do  induction  on 
the  fixed  point  term  that  appears  on  the  left  hand  side.  Each  proof  then  proceeds 
by  CASES,  SIMPLification  and  USEs  of  monotonicity  theorems  (extensive  use  is  also 
made  of  the  lemmas  of  Fig  8.2). 

Having  established  **6,  it  is  easy  to  prove  the  complementary  results. 


H Vx  a al.  Q(al)*  evlis(x,a)  s app!y(SevlisB,(x  a),al)  , 

H Vx  a al.  Q(al)=*  evcon(x.a)  e apply(SevconB,(x  a),al)  , 
h Vxa  al.  Q(ab*  apply(x,a)  e apply(SapplyB,(x  a),al) 

and  also 

**7  islist(AL):-T,  fl(eval(X,A))*T  H eva|(x,a)sapply(Seval,(x,a),AL) 


which  is  a statement  of  Partial  Correctness  for  EVAL,  since  it  says  that  for 
any  expression  which  can  be  evaluated  in  the  context  of  a certain  association  list 
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GOAL  VX  A AL.  islist(A)*  assoc(EVAL,ALHEVAL»SevalB)=> 
ci(X)*  as3oc(EVCON,ALHEVCON‘SevconB)* 

[mG.[xc  a.  (B(hd(hd(c)),a)=T)->B(hd(tl(hd(c))),a), 
(B(hd(hd(c)),a)=F)^G(tl(c)Ia),l]](X,A) 

£ apply(SevconBlX«(A‘NIL),AL); 


GOAL  VX  A AL.  islist(A)=>  af>soc(EVAL,ALMEVAL*SevalB)* 
a(X)=>  assoc(EVLIS,ALHEVLIS-SevlisB)* 

[/iG.[xm  a.  null(m)-»NIL,B(hd(m),a)‘G(tl(m),a)]](X,A) 
= apply(  Se  vli$B,X«(  A«NIL),AL); 


GOAL  VFN  X A AL.  islist(A)*  assoc<EVAL,AL)=(EVAL‘SevalB)* 

£KX)*  a$soc(  APPLY, AL)-(APPLY’SapplyB)* 

[/iG.[xfn  x a.  ei(x)  ->  islist(a)  -» 

(fn-CAR)  ->  hd(hd(x)), 

(fn-CDR)  -4  tl(hd(x)), 

(fn=C0NS)  - hd(x)*hd(tl(x)), 

(fn=AT0M)  -*  atom(hd(x))  -»  T,  F, 

(fn=EQ)  -♦  [xx  y.  atom(x)-»atom(y)-+(x=y),  i,  i] 

(hd(x),hd(tl(x»)-+  T,  F, 
atom(fn)  -*  G(B(fn,a),x,a), 

(hd(fn)=LAMBDA)  -♦  B(hd(tl(ti< fn>)>,  pairlis(hd(tlfn)),x,a)), 
<hd(fn)=LABEL)  - G(hd(tl(tl(fn))),x, 

((hd(tl(fn))*hd(tl(tlfn))))«a)), 
i,  i,  1 ]](FN,X,A) 


apply(SapplyB,FN'(X-<  A«NIL)>,AL>; 


GOAL  VX  A AL.  islist(A)*  assoc(EVAL,Al.)=(EVAL«SevalB)=> 
ci(X)*  assoc(EVLIS,AL)=(EVUS«SevlisB)* 

islist(app!y(SevlisB,X»(A-NIL),AL)>  s T; 


Figure  8.4  - The  Important  Partial  Correctness  Subgoals. 
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(of  variable  bindings),  the  function  induced  by  Seval  (under  interpretation)  will 
correctly  evaluate  it. 

It  remains  only  to  comment  that  the  total  amount  of  proof  generated  so  far 
in  this  proof  of  correctness  of  the  interpreter  is  quite  large  and  has  pushed  the  LCF 
system  to  its  limits.  The  proofs  of  the  lemmas  of  Fig.  8.2  each  required  a seperate 
core  image  and  the  proof  mentioned  in  this  section  required  the  largest  core  image 
possible  ( 1 28K  of  which  50K  is  the  LCF  system).  The  main  reason  for  the  gross  size 
of  the  proofs  was  the  magnitude  of  the  formulae  involved  but  there  were  over  a 
thousand  steps  involved  too.  Moreover  the  CPU  time  involved  was  rather  large  (just 
over  a hundred  minutes)  reflecting  a huge  amount  of  work  done  by  simplification  - 
many  thousands  of  substitutions  automatically  performed.  It  must  be  stressed  that 
were  it  not  for  the  partial  automation  afforded  by  the  simplification  mechanism  of 
LCF , such  a formal  proof  would  not  have  been  possible. 


8.6.  Total  Correctness! 


We  know  from  our  informal  reasoning  that  the  '£i(eval(X,A))=Tf  condition  of 
(*+7)  can  be  dropped  to  give 

islist(AL)-T  F Vx  a.eval(x,a)  s app|y(Seval,(x  a),AL) 
but  to  establish  this  formally  we  need  yet  to  prove  the  other  half  of  (**1),  namely: 


Vx  a al.  assoc(EVAL,alMEVAL"SevalB)* 

apply(SevalB,  (x  a),  al)  e eval(x,a) 
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This  goal  is  naturally  tackled  by  first  expanding  the  left  hand  side  a little  so 
that  the  'apply5  vanishes  and  we  have  an  'eval’  there  Instead.  Remembering  that 
SevalB  is  a LAMBDA  term  we  actually  get  the  subgoal 


Vx  a al.  assoc(EVAL,alMEVAL'SevalB)* 

eval(hd(tl(tl(SevalB))),(X*xM(A*a)*al»  s eval(x,a) 


which  is  appropriately  attacked  by  induction  on  the  definition  of  'eval5. 

Once  the  induction  is  initiated,  we  are  then  faced  with  the  work  of  breaking 
down  the  structure  of  the  S-expressions  SevalB,  SapplyB  etc.  that  appear  In  the 
left  hand  side  before  we  can  hope  to  apply  the  inductive  hypothesis.  However,  in 
the  subgoal  to  be  proved  there  is  NO  occurrences  of  ’eval’,  ’apply’  etc.  There  is 
thus  little  chance  to  use  SIMPLification  since 

(a)  the  theorems  we  have  found  so  useful  (so  far)  have  ’apply’, 

'eval5  etc.  on  the  left  hand  side. 

(b)  we  are  forced  to  deal  with  inequalities  since  the  results  we 
must  use  to  break  down  the  left  hand  side  are  lemmas  such  as 

* B 5 eval  Vx  a.  B((CAR  x),a)  e hd(B(x,a))  ’ 
instead  of  using  theorems  of  the  form 

' h Vx  a.  eval((CAR  x),a)  a hd(eval(x,a))  ’ . 

At  this  point,  it  appears  that  to  pursue  the  current  objective  will  demand 
repeating  all  the  work  which  preceded  the  proof  of  the  first  half  of  (**1)  in  a 
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slightly  more  general  form  (as  illustrated  by  the  last  2 theorems).  Furthermore  to 
complete  the  proof  we  are  faced  with  an  approximately  parallel  proof  (to  that 
described  in  the  last  section)  but  where  SIMPLification  was  used  before  we  will 
need  to  use  rnonotonicity  results.  Now  since  the  current  LCF  system  is  so  biased 
towards  equalities,  the  second  half  of  the  proof  would  be  extremely  tedious  using 
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% 

I 
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the  present  system. 

Because  of  this  argument,  the  formal  proof  of  the  total  correctness  of  the 
EVAL  function  was  not  carried  out.  It  can  again  be  given  consideration  when  a 
version  of  the  LCF  system  is  available  which  can  give  as  much  assistance  with 
monotonicity  arguments  as  the  current  system  gives  with  substitutions. 
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CHAPTER  9 

Compiler  Correctness  (I)  - Language  Definitions 


In  this  chapter,  we  describe  axiomatically  based  theories  of  the  source  and 
target  languages  of  the  simple  compiler  LComO.  We  cannot  apply  the  Theory  of 
Pure  LISP  {except  by  way  of  example);  instead  we  must  build  an  alternative  (albeit 
similar)  set  of  axioms  and  theorems  for  LComO  LISP  (so-called).  For  each  of  the 
languages,  the  formal  definition  will  be  preceded  by  an  informal  description. 


9.1.  Extensions  to  the  Environment*. 


As  in  Chapter  6,  we  precede  axiomatisation  of  languages  with  some 
extensions  to  the  environment  described  in  Chapter  4.  We  identify  the  axioms 
introduced  in  this  section  by  names  of  the  form  EEn. 

** AXIOM  EE1: 


Vx.  isname(x)->  isint(x)->l,  atom(x)->x,i, ' 

isint(x)-»  atom(x)->x,i,  x a x 


Vx.  ci(discr(x))s  isname(x)  a T 

Vx.  isname(x)*  discr(gensym(x))>discr(x)  a T 


isSexprn  - [/iG.[xx.  null(x)-*T,  isname(x)->T, 
isint(x)-*T,  atom(x)-*F, 
G(hd(x))-»G(tl(x)),F]] 
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These  axioms  introduce  names  (in  general),  define  S-expressions  and 
provide  the  appropriate  properties  of  the  functions  'discr’  and  'gensymT  ’discr’  is 
the  same  function  that  was  described  in  Chapter  6 but  is  specified  more  completely 
by  these  axioms.  The  important  property  of  'gensyrrv  is  that  it  maps  names  onto 
names  in  such  a way  that  if  we  build  sequences  of  names  by  successive  application 
of  the  function  then  no  item  appears  more  than  once. 

We  also  have  many  specific  names  to  introduce  and  the  technique  for  doing 
this  has  been  illustrated  several  times  so  we  will  just  point  out  the  effects  of 
several  axioms: 

♦ ♦AXIOM  EE2  Introduces  the  reserved  words  of  (he  source  language 

of  the  compiler  (a  subset  of  LISP): 

I LAMBDA,  QUOTE,  COND,  AND,  OR,  T . 

**AXIOM  EE3  Introduces  the  built-in  function  of  the  LISP  subset: 

GREATERP,  NUMBERP,  GENSYM,  EQUAL,  MINUS,  TIMES, 

ATOM,  CONS,  PLUS,  CAR.  CDR,  NOT  . 

♦♦AXIOM  EE4  Introduces  the  names  of  some  basic  LISP  functions: 

DIFFERENCE,  APPEND,  LENGTH,  ISLIST,  APPN2,  ASSOC, 

LESSP,  LIST,  NULL  . ’ ’ 

♦♦AXIOM  EE5  Introduces  the  special  words  of  the  target  language- 
JUMPE,  JUMPN,  MOVEI,  CALL,  JRST,  MOVE,  POPJ, 

PUSH,  SUB,  C,  E,  P . ’ 

♦♦AXIOM  EE6  Introduces  names  of  the  compiler  functions; 

COMPANDOR,  C0MB00L,  COMCOND,  COMPEXP,  COMPLIS 
LOADAC,  MKPU5H,  COMP,  PRUP  . ’ 

♦ ♦AXIOM  EE 7 Introduces  names  that  are  used  as  formal  parameters- 

VARS,  EXP , FLG,  VPR,  FN,  LI,  L2,  NL,  K,  L, 

M,  N,  U,  X,  Y,  Z . 


9.2.  LComO  LISP: 

It  was  mentioned  that  LComO  (McCarthy’s  compiler  discussed  by  London  in 
[13])  compiles  a certain  subset  of  LISP  which  we  will  call  LComO  LISP.  It  should  be 
noted  that  LComO  is  also  written  in  LComO  LISP. 

9.2.1.  Informal  Description 

The  language  (LComO  LISP)  is  rather  similar  in  scope  to  Pure  LISP  but  the 
few  differences  are  rather  important;  in  LComO  LISP: 

i)  the  AND  and  OR  constructions  of  LISP  1.5  are  available; 

ii)  falsehood  is  represented  as  NIL  (as  opposed  to  F in  Pure  LISP)  and 

(although  most  predicates  will  return  either  T or  NIL)  tests  for 
truth  are  tests  of  inequality  with  NIL; 

iii)  NIL  evaluates  to  NIL; 

iv)  there  is  no  LABEL  construction  and  no  functional  arguments; 

v)  functions  are  introduced  by  fiat  at  the  top  level  (and  there  will  be 

a global  A-list  for  function  definitions); 

vi)  S-expressions  are  based  on  integers  as  well  as  NIL  and  names; 

vii)  the  built-in  functions  are  CAR,  CDR,  CONS,  ATOM,  EQUAL,  LIST,  NOT, 
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PLUS  TIMES,  MINUS,  NUMBERP,  GREATERP  and  GENSYM;  (These 
functions  are  the  same  as  in  regular  LISP  except  that  ’GENSYM’ 
takes  a name  as  input  rather  than  remembering  the  last  name  it 
generated.) 


9.2.2.  Formal  Description 

Figure  9.1  gives  an  axiom  ( SL1  ) in  which  the  main  functions  of  an 
interpretive  semantics  for  LComO  LISP  are  defined  and  Figure  9.2  completes  the 
axiomatisation  of  LComO  LISP  (with  axiom  SL2  ) by  giving  the  meanings  of  the  built- 
in  functions  (CAR,  CDR  etc.).  (We  identify  the  axioms  related  to  the  LISP  subset  by 
names  of  the  form  'SLn’  where  ’SL’  denotes  'Source  Language’.)  This  formal 
description  of  the  language  parallels  the  definition  of  Pure  LISP  semantics  so  we  will 
avoid  lengthy  discussion.  However,  we  will  emphasize  that  there  are  two  A-list 
parameters  for  'eval’  etc.;  the  first  is  used  to  store  variable  bindings  and  the  second 
(constant  through  the  levels  of  recursion)  gives  function  definitions.  If  the  equations 
(of  Figure  9.1)  are  a I'ttle  hard  to  follow  then  a glance  at  Figure  9.3  might  help  since 
it  shows  the  recursive  equations  of  which  'eval’,  'apply’  etc.  are  the  mutually  least 
fixed  points, 
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** AXIOM  SL1: 

eval  a |>B.  evalF(B)], 
evalF  a [xB  x vb  fl.  3(vb)  -♦  d<f|)  -» 
null(x)  -♦  NIL, 
isint(x)  ->  x, 

isname(x)  ->  tl(assoc(x,vb)), 
atom(x)  -♦  l, 
hd(x)=QUOTE  - hd(tl(x)>, 
hd(x)=COND  -*  [/iG.evconF(B,G)](tl(x),vb,fl), 
hd(x)=AND  -♦  [/iG.evandF(B,G)]  (tl(x),vb,fl), 
hd(x)=OR  -♦  |>G.evorF(B,G)]  (tl(x),vb,fl), 
|>G.applyF(B,G)] 

( hd(x),  |>G.evlisF(B,G)](tl(x),vb,fl),vb,fl), 

r 1,  1], 
evcon  a [mg.  evconF(eval,G)], 

evconF  = [xF  G x vb  fl.  null(F(hd(hd(x)),vb,fl))-»G(tl(x),vb,fl), 

r F(hd(tl(hd(x))),vb,fl)], 

evand  a [^G.  evandF(eval,G)], 

evandF  a [xF  G x vb  fl.  null(x)->T,  null(F(hd(x),vb,fl))-»NIL,G(tl(x),vb,fl)], 


evor  s [mG.  evorF(eval,G)], 

evorF  “ [xF  G x vb  fl.  null(x)-*NIL,  null(F(hd(x),vb,fl))^G(tl(x),vb,fl),T], 


flffl)  -» 


apply  3 [nG.  applyF(eval,G)], 
applyF  a [xF  G fn  x vb  fl.  a(x)  -*  a(vb) 
isBF(fn)  -*  applyBF{fn,x), 
isname(fn)  -♦  G(tl(assoc(fn,fl)),x,NIL,fl), 

(hd(fn)=LAMBDAH  F(hd(tl(tl(fn))),pairlis(hd(tl(fn)),x,vb),fl), 

1, 1, 1, 1 ], 

evlis  n [^G.  evlisFfeval.G)], 

evlisF  n [xF  G m vb  fl.  null(m)-*NIL,  F(hd(m),vb,fl)-G(tl(m),vb,fl)], 


pairlis  a [mG.[xx  y vb.  null(x)  -»  vb,  (hd(x)-hd(y))»G<tl(x),tl(y),vb)]] 


Figure  9.1  - Axioms  for  LComO  LISP. 
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♦:*AXIOM  SL2: 

igBF  [xx.  (x=CAR)-*T,  (x=CONS>-T,  (x=MINUSWT, 

(x=CDR)-T,  (x=PLUSHT,  (x-GENSYMHT, 

(x-NOD-T,  (x=EQUAL)->T,  (x=NUMBERPHT, 

(x-ATOMHT,  (x=TIMES)-»T,  (x=GREATERP)-*T, 

(x=LIST)] , 

applyBF(CAR)  • [xx.  hd(hd(x))], 
applyBF(CDR)  ■«  [xx.  tl(hd(x))], 
applyBF(ISIOT)  « [xx.  null(hd(x))-*T,Nlt], 
applyBF(ATOM)  -■  [xx.  atom(hd(x))-*T,NIL], 
applyBF(CONS)  » [xx.  hd(x)’hd(tl(x))], 
applyBF(LIST)  s [xx.  x], 
applyBF(PLUS;  s [xx.  hd(x)+hd(tl(x})], 
applyBF(EQUAL)  ■ [xx.  hd(x)=hd(tl(x))-*T,NIL], 
applyBFvTIMES)  3 [xx.  hd(x)*hd(tl(x))], 
applyBF(MINUS)  = [xx.  mns(hd(x))], 
applyBF(GENSYM)  - [xx.  gensym(hd(x))], 
applyBF(NUMBERP)  ••  [xx.  isint(hd(x))-*T,NIL], 
applyBF(GREATERP)  [xx.  (hd(x)>hd(M(x)))->T,NlL] 

Figure  9.2  - The  Built-in  Functions  of  LComO  LISP. 
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eval  ■ [x  x vb  fl.  3(vb)  -*  3(fl)  -» 
null(x)  -*  NIL, 
isint(x)  -*  x, 

isneme(x)  -*  tl(assoc(x,vb)), 

stomfx)  -*  1, 

hd(x)=QUOTE  -*  hd(tl(x», 

hd(x)=COND  -*  evconF(tl(x),vb,fl), 

hd(x)=AND  -*  evandF(tl(x),vb,fl), 

hd(x)=OR  -*  evorF(tl(x),vb,fl), 

applyFf  hcKx),  evlisF(tl(x),vb,fl),  vb,  fl),  1, 1], 

evcon  e [xx  vb  fl.  null(eval(hd(hd(x)),vb,fl))-*evcon(tl(x),vb,fl), 

eval(hd(tl(hd(x))),vb,fl)], 

evand  s [xx  vb  fl.  null(x)-*T,  null(eval(hd(x),vb,fl))-»NIL, 

evand(tl(x),vb,fl)], 

evor  a [xx  vb  fl.  null(x)-*N!L, 

nulKeval(hd(x),vb,fl))-*evor(tl(x),vbffl)J], 

apply  a [xfn  x vb  fl.  3(x)  -►  3(vb)  -+  3(fl)  -* 
isBF(fn)  -*  applyBF(fn,x), 
isname(fn)  ■+  apply{tl(assoc(fn,fl)),x,NIL,?l), 

(hd(fn)=LAMBDA)-»  eval(hd(tl(tl(fn))),pairlis(hd(tl(fn)),x,vb),fl), 

1, 1, 1, 1 l 


evlis  s [xm  vb  fl.  null(m)-*NIL,  eval(hd(m),vb,fl)*evlis(tl(m),vb,fl)], 


Figure  9.3  - Relationships  Between  'eval’,  'apply’  etc. 
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9.2.3.  Theory  of  LComO  LISP 

L 

As  we  did  with  Pure  LISP,  we  prepare  for  applications  by  developing  a 
'theory'  based  on  the  axioms.  We  do  two  things  in  this  regard.  First,  we  define  some 
basic  LISP  functions  (actually  the  ones  we  need  for  the  compiler  proof)  such  as 
DIFFERENCE  and  LENGTH.  Next  we  assemble  a collection  of  theorems  (mainly 
oriented  towards  SIMPSET  inclusion);  we  exhibit  these  as  an  Appendix. 

The  definitions  of  the  basic  LISP  functions  that  we  want  are  given  in  Figure 
9.4  and  are  given  as  the  actual  entries  of  the  function  definition  A-list  (namely: 
function-name/function-body  pairs). 

0 

9.2.4.  ’r,r D"  - Basic  Functions  Defined 

We  will  never  actually  construct  a function  list  but  we  require  a predicate 
which  says  that  all  the  basic  functions  are  declared  in  some  given  function  list. 

( 'BFD'  is  mnemonic  for  'Basic  Function  Defined’): 
m AXIOM  SL3: 

BFD  - [xfl.  tl(as$oc(NULL,fl))---Snull  -» 

tl(assoc(DIFFERENCE,fl))-Sdifference  -* 
tl(asooc(ISLIST,fl))=Sislist  -» 
tl(as5oc(/\SS0C,fi))«  Sassoc  -* 

1 1 ( assoc( LENGTH.f I) ) -Slengt h - 
tl(asooc(APPEND,fl))=Sappend,F,F,F,F,F] 
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**AXIOM  SL4: 

Snull  * (LAMBDA  (X)  (EQUAL  X NIL)), 

Sdifference  * (LAMBDA  (X  Y)  (PLUS  X (MINUS  Y))), 

Sislist  3 (LAMBDA  (X)  (COND 

((NULL  X)  (QUOTE  T)) 

((ATOM  X)  NIL) 

((QUOTE  T)  CISLIST  (CDR  X)))))f 

Sassoc  *»  (LAMBDA  (X  Y)  (COND 
((NULL  Y)  NIL) 

((EQUAL  X (CAR  (CAR  Y)))  (COND 
(OSLIST  Y)  (CAR  Y)))) 

((QUOTE  T)  (ASSOC  X (CDR  Y))))), 

Slength  * (LAMBDA  (X)  (COND 
((NULL  X)  0) 

((QUOTE  T)  (PLUS  1 (LENGTH  (CDR  X)))))), 

; Sappend  = (LAMBDA  (X  Y)  (COND 

((NULL  X)  Y) 

((QUOTE  T)  (CONS  (CAR  X) 

(APPEND  (CDR  X)  Y))))), 


Figure  9.4  - Some  Basic  LiSP  Functions. 
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9.2.5,  Well-Formedness  Predicate 

We  give  as  Figure  9.5  the  definition  of  a predicate  'iswfe’  (IS  Well  Formed 
Expression)  which  tells  whether  an  S-expression  is  structurally  good  LISP  code.  It 
is  important  because  it  will  be  seen  later  that  LComO  will  be  total  on  inputs  that 
satisfy  iswfe".  .Note  that  one  of  the  things  checked  is  that  functions  are  not  called 
with  mom  than  a certain  number  mna  of  arguments.  Note  also  that  all  variables 
referred  to  inside  a well  formed  expression  must  be  bound  by  occurring  in  the 
formal  parameter  list  of  a LAMBDA  term. 


9.3.  LComO  LAP  - Informal  Description! 


McCarthy's  compiler  translates  the  subset  of  LISP  that  we  call  LComO  LISP 
into  LAP  - a special  version  of  PDP10  assembly  code  which  is  oriented  toward  LISP 
compilation  (LAP  is  an  acronym  for  LISP  Assembly  Program).  0?  course,  only  a 
subset  of  the  PDP10  instruction  set  is  generable  by  the  compiler  and  so  we  will  be 
concerned  only  with  certain  variants  of  nine  instructions  (given  below)  although 
our  formal  description  will  allow  later  and/or  more  complete  specification  of  the 
language.  Apart  from  simply  considering  a subset  of  LAP  we  make  some  simplifying 
assumptions  about  the  behaviour  of  the  PDP10;  we  point  out  these  idealisations 
below. 
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♦♦AXIOM  SL4: 

iswfe  s [xe.  iswfl(e,NIL)], 
iswfle  s [xe.  iswf ^iswfe.e.NIL)], 


iswf  1 3 [#iG.[xe  vl. 

nullfeHT, 

(e=T)-*T, 
isint(e)-T, 
atom(e)-*mem(e,vl), 
(hd(e)=QUOTEMsSexprn(tl(e)), 
(hd(e)=AND)->iswf2(G,tl(e),v|), 
(hd(e)=OR)->iswf2(G,tl(e),v|), 
(hd(e)=CONDHswf3(G,tl(e),vl), 
at om< hd( e))-*  ( I engt h( 1 1( e) ) > mna) -»F, 

iswf2(G,tl(e),vl), 

iswf4(G,e,vl)]], 


iswf2  = [mH.[xG  x vl.  null(x)-'T, 

G<  hd<  x),vl>-*H(  G,tl<x),vl),IF]], 


iswf3  ^ [^H.[xG  x v|.  null(x)-VT, 

G(hd(hd(x)),vl)->  G<hd(tl(x)),vl>-*  H(G,tl(x),vl),F,F]], 


iswf4  3 [xG  x vl.  (hd(x)=LAMBDA)-*  iswf5(hd(tl(x)))-» 

length(hd{tl(x)))>mna  - G(hd(tl(tl(x))),vl^hd(tl(x))),F,F]], 


iswf5  ^ [^H.[xx.  null(x)-*T,  isname(hd(x))-*H(tl(x)),F]] 


Figure  9.5  - Well-Formedness  of  LISP  expressions. 
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In  our  simplified  view  of  the  architecture  of  the  PDP10,  we  take  it  to  be 

» 

simply  a Central  Processing  Unit  and  a Memory.  The  CPU  executes  lists  of 
instructions  and  each  instruction  executed  can  affect  the  flow  of  control  in  certain 
ways  and/or  affect  the  state  of  the  memory.  The  memory  is  an  infinite  array  of 
words  such  that  every  word  has  an  address  which  is  a positive  integer.  Also  the 
first  sixteen  words  can  be  used  as  accumulators  or  index  registers. 

We  do  not  want  to  become  involved  in  the  processes  of  assembling  or 
loading  of  LAP.  Also,  we  do  not  admit  the  possibility  that  LAP  instructions  will  be 
overwritten  during  the  execution  of  a program.  Hence  we  make  the  further 
assumption  that  LAP  code  is  interpreted  directly  (symbolically)  and  not  resident  in 
memory  in  any  way. 

The  contents  of  words  of  the  PDP10  are  usually  treated  as  integers  but  we 
also  want  to  represent  S-expressions  in  memory.  We  do  not  want  to  get  involved 
in  questions  of  representation  so  we  just  say  that  there  exists  a coding  of  S- 
expressions  into  integers.  The  only  thing  we  specify  about  the  coding  is  that  it  is 
one-to-one  and  that  the  coding  of  NIL  is  0.  This  assumption  enables  us  to  avoid  any 
questions  related  to  free-storage  management.  Further  note  that  there  is  no  bound 
to  the  integers  that  words  may  contain.  Moreover,  we  assume  that  the  contents  of 
any  word  is  only  defined  if  a value  has  been  written  in  alre  ady. 

Now  just  as  an  LComO  LISP  program  is  a collection  of  LISP  functions,  we 
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take  a LAP  program  to  be  a collection  of  LAP  functions;  we  define  a LAP  function  to 
be  triple  (FN.NA.FB)  where  'FNP  is  the  lunction  name,  'MA'  is  the  number  of 
arguments  of  the  function  and  TB’  is  the  function  body.  Functions  expect  their  n 
arguments  loaded  in  the  accumulator-!  1 to  n;  a function  body  is  a list  of  S- 
expressions  which  are  either  labels  (if  atomic)  or  instructions. 

We  now  come  to  describe  the  nine  instructions  that  LComO  makes  use  of 
(we  use  C[n]  to  stand  for  "contents  of  accumulator  n"): 


(JRST  0 L) 
(JUMPE  n L) 
(JUMPN  n L) 


is  an  unconditional  jump  to  label  L in  the 
current  function; 


causes  a jump  to  L in  the  current  function  if 
contents  of  accumulator  n is  zero; 


causes  a jump  to  L in  the  current  function  if 
contents  of  accumulator  n is  nonzero; 


(MOVEI  n (QUOTE  x))  contents  of  accumulator  n ( C[n]  )is  set  to 

the  coding  of  S-expression  x; 


(MOVE  n m P) 


C[n]  is  set  to  C[  C[!P]  + m] 


(PUSH  P n) 

(SUB  P (C  0 0 n nj)  decrements  the  stack  pointer  (acc  !P)  by  n; 


increments  the  stack  pointer  (acc  !P)  by  one 
and  puts  C[n]  on  the  stack; 


(CALL  n FN) 


current  routine  is  suspended  and  control 
passes  to  function  in  program  with  name  FN 
(which  presumably  has  n parameters)  after 
incrementing  stack  pointer  by  one;  If  FN  is  a 
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standard  function  it  will  restore  the  value  of 
stack  pointer  before  entry  and  leave  its 
result  in  accumulator  1; 


(POPJ  P) 


return  from  current  function  to  instruction 
after  the  one  that  CALLed  the  current  fun. 
(stack  pointer  is  decremented  by  1); 


The  particular  accumulator  numbered  !P  (referred  to  by  the  name  'P’  in  the 
above  instructions)  is  used  as  a stack  pointer.  Not*,  that  we  do  not  worry  about 
stack  overflow  since  we  are  noi  assuming  finiteness  of  memory.  Also  note  that, 
since  the  arguments  of  a function  are  passed  in  the  low  accumulators,  the  maximum 
number  of  arguments  for  a function  is  less  than  !P. 


9.4.  LGomO  LAP  - Formal  Description! 


9.4.1.  States  and  functions  on  states: 

The  notion  of  'state’,  in  the  following  semantics,  is  intended  to  reflect  the 
correspondence  between  word  addresses  and  contents  - not  as  a function  but  as  an 
association  list.  More  specifically,  a state  will  be  an  A-list  of  pairs  (n°x)  where  n is 
an  address  and  x is  the  coding  (by  function  'code')  of  an  S-expression;  a property  of 
these  A-lists  is  that  the  pairs  are  in  order  of  increasing  address. 

The  following  axiom  gives  functions  for  changing  and  interrogating  states 
and  also  other  properties  of  the  memory: 
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**  AXIOM  TL1: 

get  a [xx  st.  tl(assoc(x,st))], 


set  s [>G.[\x  y st.  null(st)-*  ^ „ y)-NIL,  (hd(hd(st))=x)->  (x*y)*tl(st), 
(hd(hd(st))>x)-»  (x-y)-st,  hd(st)-G(x,y,tl(st))]3, 


putargs  s [xa  st.  Iength(a)>mna-»i,putargx(length(a),rev(a),st)], 
putargx  2 |>G.[xn  x st.  Z(n)->  st,  set(n,code(hd(x)),G(n-l,tl(x),st))]], 


argsin  a [xa  st.  length(a)>mna-*F,argsinx(length(a),rev(a),st)], 
argsinx  a [^G.[xn  x st.  Z(n)->  T,  (get(n,st)=hd(x))->G(n-l,tl(x),st),F33, 


PDL  > !P  a T, 
!P  > mna  a T, 
mna  >2^1, 


code(NIL)aO, 

Vx.  dec(code(x))sx 


The  function  'get’  is  for  interrogating  the  memory  and  takes  one  argument  - 
an  address;  the  function  'set’  is  used  for  putting  information  in  the  memory  and  its 
arguments  are  an  address  and  a value,  'putargs’  puts  a list  of  arguments  (values) 
into  the  accumulators  starting  at  number  1;  'argsin’  testifies  that  a list  of  arguments 
is  already  contained  in  the  accumulators  (starting  at  1).  The  constant  'mna’  denotes 
the  maximum  number  of  arguments  for  functions  while  MP’  is  the  address  of  the 
stack  pointer  (an  index  register). 
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9.4.2.  LAP  Functions  and  operations  on  them: 

We  have  characterised  a LAP  program  as  a collection  of  LAP  functions  and 
so  a program  is  a sort  of  environment  in  which  to  execute  function  calls.  Actually  in 
the  axiomatisation  a program  will  be  an  A-list  from  which  we  can  extract  function 
bodies  and  check  numbers  of  parameters.  The  function  'body’  does  just  this: 

** AXIOM  TL2: 

| body  3 [xfn  P n.  <n>hd(tl<assoc<fn,P))))->tl(tl<assoc<fntP))),  1] 

Now  when  we  are  dealing  with  a LAP  function  we  want  to  consider  it 
simply  a sequence  of  instructions  and  labels.  Hence  the  LCF  functions  we  define  in 
the  axiom  below  are  applicable  to  all  groups  of  instructions  and  labels: 

**AXIOM  TL3: 

INST  - \nR  [xg  n.  atom(hd(g))-*H(tl(g),n),Z(n)-»hd(g),H(tl(g),n-l>]], 

loc  -•*  f^H.  [xx  g.  atom(hd(g))-»  (hd<g)=x)-*0,H(x,tl(g)),  H(x,tl(g))+1]], 

GL  " |/iH.  [xg.  null(g)-0,  atomfhdfg))-*  H(tl(g)),  H(tl(g))+1]], 

complete  n [xg  exc.  comp2(g,labs(g)Kexc)], 

comp2  ~ [/iH.[xg  labs.  null(g)-T,  atom(hd(g)HH(tl(g),labs), 
isJUMP(hd(hd(g))>  -* 

mem<hd(tl(tl<hd(g)))),labs)-+H(tl(g),labs),F, 

H<tl(g),labs)]], 

. labs  » [/<H.[xg.  null(g)-*NIL,atom<hd(g))  -»  hd(g)‘H(tl(g)),  H(tl(g))]] 
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If  X is  a group  of  instructions  and  labels  then  'INST(X,  n)’  will  pick  out  the 
n-th  instruction,  'GL(X)’  will  compute  the  number  of  instructions  In  X,  'labs(X)’  will 
list  all  the  labels  in  X and  'loc(L,  X)’  will  compute  the  number  of  instructions  that 
precede  label  L in  X. 

The  predicate  'complete’  is  used  to  indicate  whether  all  labels  referred  to 
by  'JUMP  instructions’  (in  a group  of  instructions  and  labels)  are  also  in  the  group  or 
in  a list  (of  labels)  which  is  the  other  parameter. 


9.4.3.  Interpreting  LAP. 

The  highest  level  function  of  the  semantics  of  LAP  will  be  called  'lap’  and 
will  take  three  arguments;  'lap(F,  L,  P)’  is  to  be  the  result  of  executing,  Inside 
program  P,  the  function  P with  actual  parameter  list  7*  (of  S-expressions). 

The  next  level  of  interpreting-function  must  manage  the  'flow  of  control’ 
within  function  bodies  - or,  more  generally,  within  arbitrary  sequences  of  labels  and 
instructions.  Defined  below  is  a function  'exec’  which  gives  the  effect  (on  a state) 
of  executing  a group  of  orders  (from  some  point  onwards)  in  the  context  of  some 
program.  More  particularly,  'exec(G,  P,  o,  st)’  will  be  the  (possibly  flagged)  state 
produced  by  executing  G (a  group  of  instructions)  from  P (a  program)  starting  at 
the  c-th  instruction  of  G and  with  initial  state  st.  States  are  flagged  while 
executing  a group  of  orders  to  indicate  that  an  'exit’  instruction  such  as  ’(POPJ  P5’ 
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has  been  encountered.  This  flagging  (accomplished  by  pairing  T with  the  state)  is 
undone  when  control  gets  back  to  the  instruction  that  ’called’  the  function  being 
executed. 

Naturally,  the  function  'exec’  is  written  in  terms  of  the  meanings  of 
individual  orders.  Now,  since  no  instruction  may  do  more  than  affect  the  memory 
and  cause  a transfer  of  control  to  its  label,  we  are  able  to  specify  the  semantics  of 
individual  orders  by  means  of  two  LCF  functions  - 'NST’  (New  STate)  and  'TOC’ 
(Transfer  Of  Control).  To  define  these  explicitly  would  be  to  give  the  semantics  of 
the  entire  instruction  set  so  we  just  axiomatise  it  for  the  particular  cases  we  are 


interested  in. 

'TOC’  is  an  LCF  function  of  type  (D,nd-(Diml-»Dtr))  and  'TOC(I,  st)’  indicates 
whether  I (a  jump  instruction)  should  cause  a transfer  of  control  if  executed  in  st 
(an  unflagged  state).  Since  it  is  only  applicable  for  jump  instructions,  there  is  a 
predicate  'isJUMP"  whose  value  is  axiomatised  for  each  of  the  nine  instructions  we 
consider. 


'NST(I,  e,  P,  st)’  gives  the  new  state  after  executing  instruction  I in  state 
st  and  in  the  context  of  program  P;  !e’  has  the  same  type  as  'exec’  and  is  used  to 
interpret  a function  if  one  is  called  by  I.  This  'extraneous’  parameter  is  required 
because  we  want  to  define  'exec’  in  such  a way  that  it  is  not  mutually  recursive 
with  ’NST"  which  will  only  be  partially  specified. 

Here  then  are  the  definitions  for  'lap’  and  'exec’: 
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♦♦AXIOM  TL4: 


lap  ^ [xfn  args  P.  dec  (get{l,tl(exec(body(fn,P,length(args)),  P,  0, 

putargs(args,set(!P,PDL,NIL)))  )))], 


exec  b [jiH.  [xg  P c st. 

(c=GL(g))  -*  st, 

(hd(st)-T)  ■»  st, 

[\z.  H(g,  P, 

isJUMP<hd(z))  -> TOC(z,stHoc(hd(tl(tl(z))),g),(c+l), 
(c+1), 

NST(z,H,P,st))]  (INST(g,c))]], 


isJUMP(JRST)®T,  isJUMPgUMPE)*!  isJUMP(JUMPN)3T, 
isJUMP(MOVE)^F,  isJUMP(MOVEI)3F,  isJUMP(SUB)-F, 
isJUMP(PUSH)=F,  isJUMP(POPJ)3F,  isJUMP(CALL)«F  . 


Refer  to  Figures  9.6  and  9.7  for  the  specification  of  the  functions  ’NST’  and 
'TOC’,  as  appropriate,  for  each  of  the  nine  instructions  that  we  consider  in  our 
treatment  of  LAP. 


9.5.  Towards  a Theory  of  LAP. 


I 


The  aim  of  this  part  of  the  thesis  is  to  prove  the  correctness  of  LComO  and 
we  do  not  have  time  to  consider  developing  even  an  elementary  theory  of  the 
language  LAP.  However,  we  have  given  an  axiomatic  framework  for  defining  most 
aspects  of  the  language,  we  have  been  forced  to  prove  some  basic  lemmas  and  so 
we  actually  have  the  beginnings  of  a theory. 
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f*AXIOM  TL5: 

Vx.  isname(x)=*  TOC((JRST  0 x))  a [xst.  T], 

Vx.  isname(x)*  NST((JRST  0 x)) 

" [xe  fl  st.  st], 

Vx.  i$narne(x)»  TOC((JUMPE  1 x))  a [xst.  Z(get(  1 ,st)>], 

Vx.  isname(x)=>  NST((JUMPE  1 x)) 

- [xe  fl  st.  st], 

Vx.  isname(x)*  TOC((JUMPN  1 x))  = [xst.  Z(get(l,st))-*F,T], 
Vx.  isname(x)*  NST((JUMPN  1 x)) 

- [xe  fl  st.  st], 

Vx.  NST((MOVEI  1 (QUOTE  x))l 

a [xe  fl  st.  NIL"set(l,code(x),st)], 

Vx  y.  isint(y)*  NST((MOVE  x y P)> 

- [xe  fl  st.  (0>x)-»l,  (x>mna)-*l,set(x,(get(P,st)+y),st)], 

Vx.  NST((SUB  P (C  0 0 x x)))  * [xe  fl  st.  set(P,get(P,st)-x,st)], 

Vx.  (x:-0)*  NST((PUSH  P x)) 

- [xe  fl  st.[xz.  set(P,z+l,set(z,get(x,st),st)](get(P,st))], 

NST((POPJ  P))  [xe  fl  st.  T*st] 


Figure  9.6  - Partial  Semantics  of  8 Lap  Instructions. 
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♦♦AXIOM  TL6: 

Vx  y.  NST«CALL  x y)) 

s [xe  fl  st.  (x>mna)  ->  1, 

isBF(y)  -*  set(l,callBF(y,x,st),st), 

1 1(  e(  body(  y,f  l,x),f  1 ,0,NIL*  st ))  ], 

callBF(CAR)  = [xn  st.  (n>l)->hd(get(l,st)),X  ], 

callBF(CDR)  ^ [xn  st.  (n>lMI(get(l,$t)),X  ], 

callBF(CONS)  3 [xn  st.  (n>2)->  get(l,st)*get(2,st),  X], 

callBF(LIST)  * [xn  st.  [n1.[\l  l>n  ■*  NIL,  get(i,st)*f(i+l)]](l)], 

. call BF( ATOM)  ® [xn  st.  (n>l)-*atom(get(l,st))-»code(T),code(NIL),l  ], 

callBF(EQUAL)  a [xn  st.  (n>2)->  «get(l,st)=get(2,st))-*code(T),code(NIL)),  l], 


callBF(PLUS)  3 [xn  st.  (n>2)->  code(dec(get(l,st))+dec(get(2,st))),  ±], 

callBF(TIMES)  a [xn  st.  (na2)-»  code(dec(get(l,st))^dec(get(2,st))),  X], 

callBF(MINUS)  a [xn  st.  (n>l)-*code(mns(dec(get(l,st)))),X], 

callBF(GENSYM)  = [xn  st.  (ndHcodefgensymfdectgetd.st))))^  ], 

callBF(NUMBERP)  a [xn  st.  (n>lHsint(dec(get(l,st)))-*code(T),code(NIL),x  ], 

callBF(GREATERP)  « [xn  st.  (n>2)-> 

((dec( get(  1 ,st))>dec( get(  2,st)))-*code(T),code( NIL)),X  ] 


Figure  9.7  - Partial  Semantics  of  the  CALL  Instruction. 
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There  are  quite  obvious  strictness  results  for  the  various  functions  and  we 
point  out  that  they  are  proved,  but  the  important  aspect  of  the  behaviour  of  the 
various  functions  we  have  introduced  is  relative  to  their  effects  on  groups 
appended  together.  We  give  some  of  these 

|-  Vx  y.  labs(xKy)  a labs(x)Alabs(y) 

h Vx  y.  GL(xrty)  a GL(x)  + GL(y) 

H Vx  y c.  INSTfxfty.c)  a (c>GL(x))  - INSKy,  c-GL(x)), 

a(y)  -*  INSTfx.c),  1 

completcfX.D-T,  completefY.U-T  h completefX&Y.D-T 

H VL  x y.  loc(L,xKy)  a memfx.labsfx))  ■->  c'(y)-»loc(L,x),l, 

loc(L,y)+GL(x) 

By  far  the  most  important  result  that  was  proved  for  LAP  itself  gave  the 
effect  of  executing  two  groups  of  instructions  joined  together  in  terms  of  executing 
them  sequentially. 


Vx.  mem(x,labs(Gl))*  memfx,labs(G2))aF, 

complete(Gl,NIL)=T,  complete(G2,NIL)-T 
H VP  c st.  exec(GUG2,P,c,st) 

» (c>GL(Gl))-*  exec(G2,P,c-GL(G  1 ),st), 

exec(G2,P,0,exec(  G 1 ,P,c,st)> 


which  has  the  most  important  corollary  that  under  certain  suitable  conditions  on  G1 


j '■  mm 

f w 


r 


exec(Gl&G2,P,0,st)  * exec(G2,P,0,exec(Gl,P,0,st) 

We  note  that  the  proof  of  this  result  required  about  300  steps  of  LCF 
proof.  That  is,  of  course,  after  certain  simple  and  general  theorems  are  proved 
about  ’complete’,  ’labs’  etc. 


CHAPTER  10 

Compiler  Correctness  ( II  ) - Outline  of  a Proof 

Having  axiomatised  the  source  and  target  languages  of  the  compiler,  we 
turn  to  the  compiler  itself. 

10.1.  Tlie  Compiler! 

We  start  by  exhibiting  the  compiler  itself;  Figure  10.1  (next  three  pages) 
gives  the  m-expression  form  of  this  'LISP  Function’  which  (via  interpretation)  maps 
S-expressions  which  are  LISP  Functions  into  other  S-expressions  which  are  LAP 
Functions. 

In  order  to  talk  about  the  S-expression  form  of  the  compiler  we  must 
introduce  axioms  to  give  the  names  to  the  bodies  of  the  various  functions. 

♦.* AXIOM  C01 

Sappn2  n (LAMBDA  (X  Y)  (CONS  (CAR  Y)  (APPEND  X (CDR  Y)») 
etc. 

The  S-expressions  so  introduced  are  Sappn2,  Scomp,  Sprup,  Smkpush, 
Sloadac,  Scomplis,  Scompexp,  Scomcond,  Scombool  and  Scompandor. 
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appn2[x;y]  = cons[car[y];append[x;cdr[y]]]  I 


comp[fn;vars;exp]  = 

x[[nj  append[append[mkpush[n;l  ]; 

compexp[exp;minus[n];prup[vars;  1 ]; 
gensym[fn]]]; 

list[list[SUB;P;list[C;0;0;n;n;]]; 

list[POPJ;P];NIL]] 

[lengthfvars]] 


prup[varc;n]  = 

[null[vars]  -*  NIL; 

T - cons[cons[car[vars];nJ;  prup[cdr[vars];plus[n;l]]]] 

mkpush[n;m]  - 

[greatcrp[m,n]  ->  NIL; 

T -*  cons[list[PUSH;P;m];  mkpush[n;plus[m;l]]]] 


loadac[n;k]  = 

[greaterpfn;0]  -*  NIL; 

T -»  cons[list[MOVE;k;n;P];  loadac[plus[n;l];plus[k;l]]]] 


complis[u;m;vpr;nl]  = 

[null[u]  -*  cons[nl;NIL]; 

T -»  x[[x];appn2[cdr[x]; 

appn2[  ((PUSH  P 1)); 

complis[cdr[u];difference[m;l  ]; 
vpr;car[x]]]]] 
[compexp[car[u];m;vpr;nl]] 


Figure  10.1a  - The  LISP  Functions  that  Make  up  LComO 
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compexp[exp;rn;vpr;nl]  = 

[ or[null[exp];equalf exp;T]]  - listfnl;list[MOVEI;l;list[QUOTE;exDll> 
atomlexp]  - listrnl;list{MOVE;l;plus[m;cdr[assocrexp;vprmPTl 

orlequal[car[exp]:AND]iequal[car[exp];OR];equal[car[exp];NOTll-» 

append[combool[exp;minl;NILivpr;gensym[gensymrnnil: 

list[  (MOVEI  1 {QUOTE  T));  JJ 

list[JRST;  gensym[nl]]; 
nl;  (MOVEI  1 (QUOTE  NIL));  gensym[nl]]l; 
equa  car[exp];CONO]  - comcond[cdr[exp];mjnl;vpr;gensym[nl]]; 
equal[car[exp];QUOTE]  -»  list[nt;list[MOVEI;l;expll; 
atorn[car[exp]]  - 

>[[n];  append[complis[cdr[exp];m;vpr;nl]; 

append[loadac[dif  ference[  1 ;nj;  1 ]; 

list[list[SUB;P;li$t[C;0;0;n;n]]; 

r list[CALL;n;list[E;carrexpimill 

[length[cdr[exp]]];  JJJJJ 

equal[car[car[exp]];LAMBDA]  -+ 

*[[n;x];append[appn2[cdr[x]; 

compexp[car[cdr[cdr[car[exp]]]]; 

difference[m;n]; 

append[prup[car[cdr[car[exp]]]; 

difference[l;m]]; 

vpr]; 

car[x]]]; 

list[list[SUB;P;list[C;0;0;n;n]]]]] 

[length[cdr[exp]]j  complis[cdr[exp];m;vpr;nl]] 


Figure  10.1b  - The  LISP  Functions  that  Make  up  LComO  (ctd.) 
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comcond[u;m;l;vpr;nl]  = 

[null[u]  -»  list[nl;l]; 

T 3 x[[x];  x[[y];  appn2[cdr[x]; 

appn2[cdr[y]; 

appn2[list[list[JRST;l];nl]; 

comcond[cdr[u];m;l;vpr;car[y]]]]]] 

[compexp[car[cdr[car[u]]];m;vpr;cai'[x]]] 

[combool[car[car[u]];m;nliNIL;vpr;gensym[nl]]]] 

combool[p;m;l;flg;vpr;nl]  = 

[atom[p]  -»  append[compexp[p;m;vpr;nl]; 

list[li$t[  [fig  -*  JUMPN;  T -»  JUMPE];l;lj]]i 
equal[car[p];AND]  -*  [not[flg]  -»  compandor[cdr[p];m;l;NIL;vpr;nl]; 

T -*  append[compandor[cdr[p];m;nl;NIL;vpr;gensym[nl]]; 
list[list[JRST;l];nl]]]; 

equal[car[p];OR]  -*  [fig  -*  compandor[cdr[p];m;l;T;vpr;nl]; 

T -*  append[compandor[cdr[p];m;nl;T;vpr;gensym[nl]]; 
list[list[JRST;l];nl]]]; 

equal[car[p];NOT]  -*  combool[car[cdr[p]];not[flg];vpr;nl]; 

T -*  append[compexp[p;m;vpr;nl]; 

list[list[[flg  - JUMPN;  T -»  JUMPE];  1 ;l]]]] 

compandor[u;m;l;flg;vpr;nl]  = 

[null[u]  -*  list[nl]j 

T -*  x[[x]j  appn2[cdr[x];compandor[cdr[u];m;l;flg;vpr;car[x]]]] 
[combool[car[u];m;l;flg;vpr;nl]]] 


10.1.1.  Some  Slight  Changes 

Close  comparison  of  this  compiler  with  the  original  will  reveal  that  there 
are  small  differences.  We  have  already  indicated  that,  in  LComO  LISP,  the  function 
GENSYM  takes  one  argument  (usually  the  name  it  generated  last  time  it  was 
invoked)  instead  of  no  arguments  (as  in  LISP  1.5).  This  change  in  the  language  was 
compensated  by  a suitable  change  in  the  compiler:  each  function  that  could  generate 
labels  internally  acquired  an  extra  parameter  - namely,  the  next  label  to  be  used; 
also  each  of  these  functions  gave  as  result  a pair  of  next-label-to-be-generated 
and  a liot-of-instructions. 

Finally,  there  is  some  slight  saving  in  the  number  of  subsidiary  functions 
required.  For  example,  LESSP  is  avoided  by  changing  the  program  to  use  GREATERP. 


10.1.2.  Predicate  'CFD’  - Compiler  Functions  Defined 
Having  available  the  S-expression  forms  of  all  the  compiler  functions,  we 
now  introduce  an  axiom  to  define  a predicate  (on  lists)  which  can  testify  to  all  the 
LISP  Functions  used  (directly  or  indirectly)  by  LComO  being  in  a function  list: 


k*AXIOM  C02: 

CFD  a [xfl.  BFD(fl)  •* 

tl(assoc(PRUP,fl)HSprup  -» 
tl(assoc(MKPUSH,fl))-Smkpu9h  -> 
tl(assoc(LOADAC,fl))=Sloadac  -* 
tl(assoc(APPN2,fl))=Sappn2  - 
tl(assoc(COMP,fl))=Scomp  -» 
tl(assoc(COMPEXP,fl))=Scompexp  -» 
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tl(assoc(COMPLIS,fl))=Scomplis  -» 
tl(assoc(COMCOND,fl))=Scomcond  -* 
tl(assoc(COMBOOL,fl))=$combool  -* 
il(assoc(COMPAIMDOR,fl))=Scompandor, 
F.FJFJFJF,  F,F,F,F,F] 


10.2.  Meaning  of  the  Compiler: 

Figure  10.2  (next  three  pages)  gives  the  meaning  functions  that  the 
compiler  LISP  Functions  induce  under  interpretation.  Figure  10.3  contains  theorems 
which  explicate  the  definitions  of  'compexp’  and  'combool’  which  are  the  hardest  to 
follow.  We  shall  therefore  consider  the  LCF  function  'comp’  to  be  the  compiling 
algorithm  of  LComO,  The  purpose  of  introducing  the  meaning  functions  is  to  factor 
the  whole  proof  of  correctness  of  the  compiler  into  two  substantial  but  independent 
parts: 

i)  the  correctness  of  the  S-expression  form  of  LComO  relative  to  the 

compiling  algorithm; 

ii)  the  correctness  of  the  compiling  algorithm. 

The  technical  statement  of  the  first  subproblem  is  simply: 

CFD(FL)=T  h Vf  v e.  apply(COMP,(f  v e),NIL,FL)  = comp(f,v,e) 

which  we  arrive  at  via  the  family  of  lemmas: 

CFD(FL)sT  h Ve  m vpr  nl  vb.  apply(COMPEXP,(e  m vpr  nl),vb,FL) 

3 islist(vb)  -*  compexp(u,m,vpr,nl),  1 


121 


♦AXIOM  C03: 


comp 


[xf  v e.[xn.<mkpush(n,l) 

& t l(compexp(e,mns(n),prup(  v,  1 ),gensym(  f) ))) 

K v (SUB  P (C  0 0 n n))  (POPJ  F)  NIL)]length(v)], 


compexp  - [/iG,[xexp  m vpr  nl. 

(null(exp)-*T,(exp=T)-*Tr,isiri{(exp))  -* 

M (MOVEI  1 (QUOTE  exp))), 
atom(exp)  - ^nl  (MOVE  1 m+tl(assoc(exp,vpr))  P)) 

((hd(exp)--Af\JD)-+Tl(hd(exp)--OR)-»T,(hd(exp)=NOT))  -* 
comboolF(G)(exp,m,nl,NIL,vpr,gensym(gensym(nl))) 

iK  ( (MOVEI  1 (QUOTE  T))  (JRST  0 gensym(nl)) 


nl  (MOVEI  1 (QUOTE  NIL))  gensym(nl); 


(hd(exp)-COND) 

co^c°n^fr(G,comboolF(G))  (tl(exp),m,nl,vpr,gensym(nl)) 
(hd(exp)=QUOTE)  - (nl  (MOVEI  1 exp)),  ' 

atom(hd{exp))  -*  complisF(G)(tl(exp),m,vpr,nl) 

* [xn.loadac(l-n,l)  & ( (SUB  P (C  0 0 n n)) 

(hd(hd( exp}) -LAMBDA)" ''E 

r,'n  x T^<:?£pS2^<S)^<hd<^(!,l<hd<eXF>>>)>'m-n"vP'-2.hd<;<>)> 

& s\SUB  P (C  0 0 n n)))](length(il(exp)), 

complisF(G)(tl(exp),m, vpr.nl), 

vPr  * prup(hd(tl(hd{exp))),l-m)), 


complisF  - [xce.  [/iH.[xu  m vpr  nl.  null(u)-*  (nl), 

[xx.  appn2(tl(x),  appn2(  ( (PUSH  P ])), 

H( 1 K u>.m- 1 ,vpr,hd(  x))))](ce(  hd(  u),m, vpr.nl))]]], 


Figure  10.2a  'comp’  - the  meaning  of  'COMP. 
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comboolF  a [xce.  [>H.[xp  m I fig  vpr  nl. 
atom(p)  -» ce(p,m,vpr,nl) 

& ( ((null(flg)-»JUMPE,JUMPN)  1 I)), 

(hd(p)=AND) 

null(flg)  compandorF(H>(tl(p),m,l,NIL,vpr',nl), 

compandorF(H)(tl(p),m,nl,NIL,vpr,gensym(nl)) 

& ( (JRST  0 I)  nl), 

(hd(p)=OR)  -4 

null(flg)  *4  compandorF(H)(tl(p),m,nl,T,vpr,gensym(nl)) 

A ( (JRST  0 I)  nl), 
compandorF(H)(tl(p),m, I, T, vpr.nl), 

(hd(p)=NOT)  4 H(hd(tl(p)),m, I, (null(flg)4T, NIL), vpr.nl), 

ce(p,m, vpr.nl)  & ( ((null(flg)4jUMPE,JUMPN)  1 I ))]]], 


compandorF  = [xcb.  [mF.[xu  m I fig  vpr  nl.  nulKuW  (nl), 

[xx.  appn£'(tl(x),F(tl(u),m,l,flg,vpr,hd(x)))] 
<cb(hd(u),m, I, fig, vpr.nl))]]], 


comcondF  3 [xce  cb.  [/iH.[xu  m I vpr  nl.  null(u)  4 (nl  I), 

[xx.  [xy.  appn2(tl(x), 

appn2(tl(y), 

appn2(  ( (JRST  0 I)  nl), 

H(tl(u),m,l,vpr,hd(y)))))] 

(ce(hd(tl(hd(u))),m,vpr,hd(x)))] 

(cb(hd(hd(u)),m,nl,NIL,vpr,gensym(nl)))]]], 


Figure  10.2b  - Auxiliary  Functions  for  ’comp’. 
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complis  s complisF(compexp), 
combool  ~ comboolF(compexp), 
compandor  h compandorF(combool), 
comcond  r:  comcondF(compexp,  combool) 

a 

appn2  [xx  y.  hd(y)  - (x  & tl(y)>  ]( 
prup  « [#iG.[xv  n.  null(v)-»NIL,  (hd(v)*n)  • G<(l( v),n+l )]], 
mkpush  - [nG.[\r\  m.  (m>n)-*NIL,  (PUSH  P m)  • G(n,m+1)]], 
loadac  « [/iG.[xn  k.  (n>0)-*NIL,  (MOVE  k n P)  • G(n+l,k+l)]] 


Q 

Figure  10.2c  - Auxiliary  Functions  for 'comp’. 
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compexp  s [#iG.[xexp  m vpr  nl. 

(null(expHT,(exp=T)-»T,i$int(exp))  -> 

(nl  (MOVEI  1 (QUOTE  exp))), 
atom(exp)  -*  (nl  (MOVE  1 m+tl(as$oc(exp,vprj)  P)), 

( ( hd( exp) = ANDHT,( hd( exp)  =OR)-*T,( hd( exp) =NOT))  -* 
combool(exp,m,nl,NIL,vpr,gen$ym(gen$ym(nl))) 

& ( (MOVEI  1 (QUOTE  T))  (JRST  0 gensymlnl)) 
nl  (MOVEI  1 (QUOTE  NIL))  gensym(nl)), 

(hd(exp)=COND)  -* 

comcond(tl(exp),m,nl,vpr,gensym(nl)), 

(hd(exp)-QUOTE)  - (nl  (MOVEI  1 exp)), 
atom(hd(exp))  -»  complis(tl(exp),m,vpr,nl) 

& [xn.loadac(l-n,l)  & ( (SUB  P (C  0 0 n n)) 

(CALL  n (E  hd(exp))))](length(tl(exp))), 
(hd{hd(exp))=LAMBDA)  -> 

[xn  x vpr2.  appn2(tl(x),G(hd(tl(tl(hd(exp)))),m-n,vpr2,hd(x))) 
& ((SUB  P (C  0 0 n n)))](length(tl(exp)), 
complis(tl(exp),m, vpr.nl), 
vpr  & prup(hd(tl(hd(exp))),l-m)), 


1]], 


combool  s (>H.[xp  m I fig  vpr  nl. 

atom(p)  -*  compexp(p,m, vpr.nl) 

& ( «null(flgHJUMPE,JUMPN)  1 I)), 

(hd(p)=AND)  -* 

null(flg)  -*  compandor(tl(p),m, I, NIL, vpr.nl), 

compandor(tl(p),m,nl,NIL,vpr,gensym(nl)) 

* ( (JRST  0 I)  nl), 

(hd(p)=OR)  •* 

null(flg)  - compandor(tl(p),m,nl,(T,vpr,gensym(nl)) 

R ( (JRST  0 I)  nl), 
compandor(tl(p),m, I, T, vpr.nl), 

(hd(p)=NOT)  -*  H{hd(tl(p)),m, I, (null(flg)-*T, NIL), vpr.nl), 
compexp(p,m,vpr,nl)&  ( ((null(flg)-*JUMPE,JUMPN)  1 I))]]], 


Figure  10.3  - Theorems  Explicating  'compexp’  and  'comucolT 
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CFD(FL)^T  h Vu  m I vpr  nl  vb.  apply(COMCOND,(u  m I vpr  nl),vb,FL) 

a islist(vb)  -»  comcondiu.m.l.vp^nl),  1 


etc. 


The  appropriate  attack  on  these  subproblems  is  by  means  of  the  techniques 
described  in  the  context  of  Pure  LISP  (see  Chapter  7).  We  must  prove  the  family 
of  lemmas  simultaneously  using  induction  on  the  the  structure  of  the  expression 
being  compiled.  The  proof  will  clearly  be  long  and  for  this  reason  alone  we  would 
find  difficulty  in  establishing  the  results.  We  estimate  that  it  would  be  comparable 
in  size  to  that  half  of  the  interpreter  proof  that  was  done  on  the  machine. 

10.3.  Properties  of  the  Compiler  Functions. 

Having  extracted  meanings  for  the  various  compiler  functions  as  terms  of 
LCF,  we  must  proceed  to  prove  various  theorems  about  their  behaviour.  The  most 
important  one  is  treated  in  the  next  section:  that  the  compiling  functions  produce 
'correct  LAP  code.  In  this  section  we  present  some  useful  but  much  simpler  lemmas 
about  the  LCF  functions  'comp’,  'compandor’  etc. 

Attached  to  some  of  the  lemmas  there  are  provisos  that  the  arguments 
given  to  a function  are  well  formed.  We  refer  the  reader  to  chapter  9 for  the 
discussion  of  well-formedness  of  LISP  expressions. 
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Several  of  the  functions  take  a parameter  which  will  call  a variable 

position  record  (vpr).  A vpr  is  an  A-list  which  associates  variables  with 

integers  used  in  the  computation  of  stack  positions  for  variables.  The  predicate 

'isvpr(v,n)’  checks  that  v is  a vpr,  that  the  integers  are  in  descending  order  and  are 

positive  but  less  than  n.  The  function  'vprvars*  builds  a list  of  all  the  variables 

mentioned  in  a vpr. 

isvpr  = [mG.[xv  n.  null(v)  -♦  (n>l), 
tl(hd(v»>n  - F, 

isname(hd(hd(v)))  -*  G(tl(v),tl(hd(v))),  F ]] 
vprvars  a [mG.  [>x.  null(x)  ->  NIL,  hd(hd(x))  • G(tl(x))]] 

We  observe  that  *compexp\  'complis’,  'combool’,  'compandor1,  'comcond’  are 
all  strict  in  their  first  and  last  arguments  and  that  'compexp’  is  strict  in  all  its 
arguments. 

10.3.1.  Totality 

The  result  we  suggest  in  this  subsection  is  that  each  of  the  compiler 

functions  terminates  with  a list  (of  instructions)  provided  only  that  its  arguments  is 

well-formed.  Formal  statements  of  two  instances  of  this  result  are:- 

iswfe(e,vprvars(vpr))  = J, 
isvpr(vpr,mns(m))  a 
isname(nl)  s j 

H islist(compexp(e,m,vpr,nl))  = T 
and 


iswf  1 (p.vprvars(vpr))  s Jt 
jsvpr(vpr,mns(m))  3 T, 
isname(l)  3 J, 

(fig-  NIL)  T,  (flg=T)  3 I, 
isname(nl)  3 j 

H i slist(combool( p,m,l,f1g,vpr,nl> ) 3 J . 


By  instantiating  the  first  of  these  two  lemmas  appropriately  we  get: 

icwfef  (LAMBDA  v e),  NIL)  = T, 
isname(f)  3 J 

h islist(comp(f,v,e))  a T 


10.3.2.  Completeness 

We  next  suggest  some  results  which  say  that  the  bodies  of  code  produced 

by  compiler  functions  are  complete  in  the  sense  that  they  contain  no  jumps  to 

'undefined’ labels.  Take,  for  example, 'cc„  00P: 

iswf  1 (p.vpr varsf vpr))  3 Jt 
isvpr(vpr,mns(m))  3 J, 

(flg-NIL)  -*  T,  (flg=T)  3 J, 

discr(nl)  > discr(l)  3 Tf 

h complete(tl(combool(p,m, I, fig, vpr.nl)),  (I) ) = T . 


The  corresponding  theorem  for  'comp’  is: 

iswfef  (LAMBDA  v e) ) 3 T, 
isname(f)  3 y 

h complete(comp(f,v,e),  NIL)  3 T . 
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10.3.3,  Distribution  of  Labels 

When  we  come  to  prove  correctness  of  the  compiler  functions  we  will  need 

lemmas  which  declare  that  in  bodies  of  code  produced  by  the  compiler  functions, 

labels  are  declared  only  once.  This  requirement  is  fulfilled  by  some  theorems  which 

describe  the  orderly  placing  of  labels,  For  example,  we  state  the  one  for  'comcond’: 

iswf  l(u,vprvars(vpr))  3 T, 
isvpr(vpr,mns(m))  3 J, 
discr(nl)  > discr(l)  3 T, 

X = comcond(u,m,l,vpr,nl)l 
mem(y,  !abs(tl(X)j)  ® T 

[•  discr(y)  > discr(l)  a T, 
discr(hd(X))  > discr(y)  « T . 


10.4.  Statement  of  Correctness. 


Let  us  now  state  what  our  final  goal  is.  We  first  do  so  informally  as  follows: 

IF  we  have  a certain  function  list  FL1  of  well-formed  LISP 
Functions 

AND  we  have  a function  list  FL2  of  the  compiled  forms  of 
those  LISP  Functions  (where  compilation  is  done  by  running 
the  LISP  compiler  (LComO)), 

THEN  the  effect  of  applying  some  function  F to  some  list  A of 
arguments  (not  too  long)  is  the  same  whether  we  use  LISP 
'apply’  in  the  context  of  FL1  or  LAP  in  the  context  of  FL2. 


That  is,  we  must  establish  the  theorem, 

Vx.  c'(hd(assoc(x,FLl )))*  iswfe(tl(assoc(x,FLl)))3T, 

Vx.  c'(hd(assoc(x,FLl)))*  hd(tl(assoc(x,FLl)))sLAMBDA. 

CFD(FL)=T, 

Vx.  ci(hd(assoc(x,FL2)))* 

tl(tl(assoc(x,FL2)))s  applyfCOMP,  (x  hd<tl(tl(assoc(x,FL  1 )))) 

. hd(tl(tl<tl(assoc(x,FL  1 )))))  X NIL,  FL) 

r Vfn  args.  Iength{args)<mna* 

apply(fn,args,NIL,FLl)  3 lap(fn,args,FL2) 


10.4.1.  Correctness  of  the  Compiling  Algorithm 

In  Section  2 we  exhibited  the  function  'comp’  which  is  the  one  induced 
under  interpretation  by  the  LISP  function  'COMP’.  We  are  thus  entitled  to  simplify 
the  compiler  correctness  problem  by  rewriting  some  of  the  hypotheses  of  the  above 
theorem.  We  will  now  assume  those  modified  hypotheses  for  the  rest  of  the 
chapter,  effectively  creating  constants  FL1  and  FL2:- 

Vx.  ci(hd(assoc(x,FLl»)*  iswfe<tl(assoc(x,FLl)))ET, 

Vx.  c‘i(hd<assoc(x,FLl)>)=>  hd(tl(assoc(x,FLl)))sLAMBDA 
and 

Vx.  ci(hd(assoc{x,FL2)))* 

tl(tl(assoc(x,FL2)))=  comp(x,  hd(tl(tl<assoc(x,FL  1 )))), 

hd<tl(tl<tl(assoc(x,FL  1 )))))) 


The  correctness  of  the  compiling  algorithm  is  then  just: 
h Vfn  args.  Iength(args)<mna*  apply(fn,args,NIL,FLl)  3 lap(fn,args,FL2) 
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10.4.2.  The  Principal  Lemma 

Taking  the  result  of  the  last  subsection  as  our  goal,  we  see  that  the 
appropriate  principal  subgoal  is: 

Vvb  st  args  fn.  d(vb)=*  length(args)<mna=>  get(!P,st)>PDL* 

dec(get(l,exec(body(fn,FL2,length(args)),  FL2,  0,  putarg$(args,st)))) 

■ apply!  fn,args,vb,FLl) 

The  main  correctness  result  follows  from  this  one  by  taking  'vb’  to  be  'NIL’ 
and  'st’  to  be  'set(!P,PDL,NIL)’ . 

10.4.3.  Environment  Correspondence 

At  the  next  level  of  goals,  we  will  have  equations  where  the  LAP 
interpretation  of  some  expression  appears  on  the  left  hand  side  and  LISP 
interpretation  of  a corresponding  expression  appears  on  the  right.  However,  both  of 

| 

these  interpreting  functions  take  an  environment  as  a parameter  and  so  we  will 
sometimes  need  preconditions  to  the  effect  that  a pair  of  environments  are 
consistent.  We  thus  define  a correspondence  function  between  LISP  A-Lists  and 
LAP  run-time  stacks  as  follows: 

stkscorr  a [>G.[xvb  st  vpr  m. 

null(vpr)  ->  (get(!P,st)+m  > PDL), 

( hd(  hd(  vb))=hd<hd<  vpr))) 

-*  !tl<hd(vb))=get(get(!P,st)+m+tl(hd(vpr)),st) 

-»  G(tl(vb),st,tl(vpr),m),  F), 

FJ] 


One  sees  that  if  stkscorr(vb,st,vpr,m)  T then  the  value  of  any  variable 
extractable  from  the  run-time  stack  by  means  of  the  function 

fxx.  get(get(!P,.st)+m+tl(assoc(x,vpr)),st)]  is  the  same  as  the  value  which  would 
be  extracted  from  the  A-list  vb  by  means  of  the  usual  function 

[xx.  tl(assoc(x,vb))].  Note  that  this  correspondence  function  is  very  much  tailored 
to  our  present  purposes  of  proving  LComO.  A more  general  such  predicate  might 
not  require  that  variables  appear  in  exactly  the  same  order  in  the  A-list  and  the 
stack;  on  the  other  hand,  it  could  require  that  all  of  the  stack  in  st  should 
correspond  to  all  of  vb  instead  of  just  those  variables  that  are  mentioned  in  vpr. 

10.4.4.  Second  Level  Subgoals 

The  secondary  lemmas  which  we  must  prove  and  which  we  list  in  figures 
10.4  to  10.8  relate  LISP  interpretation  in  some  environment  (an  A-list)  to  LAP 
execution  of  corresponding  code  in  a corresponding  environment  (a  stack).  More 
particularly,  we  wish  to  describe  the  effects  of  executing  code  produced  by 
'compexp’,  'complis’,  'comcond’,  'combool’  and  ’compandor’  in  terms  of  how  the  LISP 
functions  'eval\  'evlis’  and  'evcon’  operate  on  the  source  S-expressions.  Note  that 
there  are  just  three  effects  we  wish  to  capture  in  lemmas  about  code  execution: 

i)  What  the  answer  is  (usually  what  register  1 contains); 

ii)  How  the  stack  pointer  is  affected; 

iii)  How  the  stack  contents  are  affected. 
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i)  Answer: 


Vexp  vb  st  vpr  m lab. 
st  kscorr(  vb,st , vpr.m)  * 
iswf  l(exp,vprvars(vpr))=> 
isname(lab)* 

dec(get(l,exec(tl(compexp(exp,m,vpr,lab)),FL2Ast))) 
s eval(exp,vb,FLl) 


ii)  invariance  of  Stack  Pointer: 

Vexp  st  vpr  m lab. 
iswfl(exp,vprvars(vpr))* 
isname(lab)* 
get(!P,st)>PDL* 

Vst  2. 

st2=exec(tl(compexp(exp,m,vpr,lab)),FL2,0,st)* 
get(!P,st2)  ■ get(!P,st) 


iii)  Invariance  of  Stack  Contents: 

Vexp  st  vpr  m lab. 
iswfl(exp,vprvars(vpr))* 
isname(lab)=* 
set<!P,st)>PDL=> 

Vst  2 n. 

st2=exec(tl(compexp(exp,m,vpr,lab)),FL2,0,st)* 

n>PDL* 

get(!P,st)>n* 

get(n,st 2)  3 get(n,st) 


Figure  10.4  - Subgoals  Describing  Effects  of  'compexp’. 


j)  Answer: 

Vx  vb  st  vpr  m yl  y2. 
stkscorr(vb,st,vpr,m)* 
iswf3(iswfl,x,vprvars(vpr))* 
discr(y2)>discr(yl)* 

dec(get(l,exec(tl(comcond(xlm,yl,vpr,y2)),FL2,0,st))) 
a evcon(x,vb,FLl) 


ii)  Invariance  of  Stack  Pointer: 

Vx  st  vpr  m yl  y2. 
iswf?fiswf  l,x,vprvars(vpr))* 
discr<y2)>discr(y  1 )=> 
get(!P,st)>PDL^ 

Vst2. 

st2=exec(tl(comcond(x,m,yl,vpr,y2)),FL2,0,st)* 
get(!P,st 2)  s get(!P,st) 


iii)  Invariance  of  Stack  Contents: 

Vx  st  vpr  m yl  y2. 
iswf3(iswfl,x,vprvars(  vpr))* 
discr(y2)>discr(yl)* 
get(!P,st)iPOL* 

Vst2  n. 

st2=exec(tl(comcond(x,m,yl,vpr,y2)),FL2,0,st)* 

n>PDL* 

get(!P,st)>n* 

get<n,st 2)  a getfn.st) 


Figure  10.6  - Subgoals  Describing  Effects  of 'comcond’. 
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Vn.  Vx  vb  st  vpr  m yl  v2  fig. 
stkscorr(vb,st,vpr,m)* 
iswf  1 (x,vprvars(  vpr))* 
discr(y2>>discr<y  1 )=s> 

(flg=T)  - T,  <flg=NIL)=> 

VxL  seql  seq2. 

xL=tl(combool(x,m,yl,flg,vpr,y2))* 

hd(seq2)=yl* 

disjoint(labs(seq2),labs(seql))=> 

disjoint(labs(seql&seq2),labs(xL))* 

get(!P,st)>n=> 

(n>PDL)-*T,(n=l)-*T,(n=!P)* 


vj 


I 


§ 


get(n,exec(xL&Geql&seq2,FL2,0,st)) 
a [xC.  get(n,exec(C,FL2,0,st))] 

(null(eval(x,vb,FLl))->(null(flg)->seq2,seql&seq2), 

(null(flg)-+$eql&seq2,seq2)) 


0 


Notes; 


i)  This  lemma  can  be  specialised  to  tell  about  answer,  stack 
pointer  or  old  stack  contents  by  taking  V to  be  1,  !P  or  some 
stack  address  (an  integer  between  PDL  and  get(!P,st)). 


U 


I 


ii)  The  predicate  ’disjoint’  searches  for  common  elements  of 
two  lists;  It  yields  F if  it  finds  one. 

disjoint  s [,«G.  [xx  y.  null(x)  -♦  T, 

mem(hd(x),y)  -*  F,  G(tl(x),y)]] 


U 


Figure  10.7  - Subgoal  Describing  Effects  of  'combool’. 
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Vn.  Vx  vb  st  vpr  m yl  y2  fig. 
stkscorr(vb,st,vpr,m)* 
iswf  1 (x,vprvars(  vpr))* 
discr(y2)>discr(yl)* 

(flg=T)  T,  (flg=NIL)* 

VxL  seql  seq2. 

xL=tl(compandor(x,m,yl,flg,vpr,y2))* 

hd(seq2)=yl* 

disjoint(labs(seq2),labs(seql))* 

disjoint(labs(seqli'vseq2),labs(xL))* 

get(!P,$t)>n* 

(n>PDL)-*T,(n=l)->T,(n=!P)* 

get(n,exec(xLK  seq  1 & seq2,FL2,0,st)) 

« [xC.get(n,exec(C,FL2,0,st))] 

([/iG.[\y.null(y)-*seql^seq2, 

null(eval(hd(y),vb,FLl))-*(null(flg)-»seq2,G(tl(y))), 

(null(flg)-*G(tl(y)),seq2)]](x)) 


Note: 

This  lemma  can  be  specialised  to  tell  about  answer,  stack 
pointer  or  old  stack  contents  by  taking  V to  be  1,  !P  or  some 
stack  address  (an  integer  between  PDl  and  get(!P,st)). 


Figure  10.8  - Subgoal  Describing  Effects  of  'compandor’. 
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10.4.5,  Attacking  the  Subgoals. 

Because  'compexp’,  'complis’  etc.  are  all  mutually  recursive,  the  subgoals  of 
figures  10.4  to  10.8  are  all  interdependent.  It  is  thus  necessary  (but  natural)  to 
attack  all  these  subgoals  simultaneously.  The  appropriate  tactic  will  clearly  be 
induction  on  the  structure  ol  all  S-expressions  being  compiled.  We  do  this  by  using 

Scott  induction  on  the  definition  ol  'iswfl'  which  occurs  in  the  relativisations  of  all 
the  subgoals. 

The  reader  who  is  unfamiliar  with  LCF  should  not  be  perturbed  at  the  large 

size  of  the  conjunction  of  all  these  formulae;  Immediately  after  the  induction  tactic  is 

performed  the  new  principal  subgoal  generated  may  be  split  back  into  manageable 
pieces. 

The  reader  may  also  wonder  whether  the  limit  on  size  of  core  image 
imposed  on  the  LCF  System  presents  a barrier  which  can  make  some  proofs 
effectively  impossible  to  do.  The  answer  to  this  question  is  that,  in  practice,  proofs 
in  the  system  tend  to  be  reasonably  well-structured  and  we  can  factor  such  proofs 
into  their  main  parts  and  subsidiary  parts  and  then  prove  subsidiary  results  in 
separate  core  images.  More  particularly,  if  a subsidiary  part  of  a proof  has  N steps, 
makes  reference  to  J previous  steps  (hypotheses  H„  H* ..  Hj ) and  contains  K steps 
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for  future  use  (results  R,,  R2)  ..  RK  ) then  as  a separate  task  we  may  attack 
H|,..,Hj  H R|,..,Rk  . Now  if  this  proof  (at  most  N+J  steps  long)  fits  In  core  and  J+K  is 
much  less  than  N (as  is  usual)  we  win. 


10.5.  Feasibility  of  a Full  Compiler  Proof 


To  sum  up,  we  have  split  the  LComO  correctness  problem  into  four  parts. 
The  first  two  were  the  developments  of  axiomatic  theories  for  LISP  and  LAP  and 
chapter  9 reported  on  the  machine  assisted  generation  of  these  theories. 

The  third  part  of  the  total  problem  was  the  proof  that  ’compexp’  etc.  are 
the  functions  denoted  by  the  S-expressions  COMPEXP  etc.  This  part  of  the 
compiler  problem  was  not  worked  up  to  a machine  checked  proof  but,  for  reasons 
cited  above,  it  was  expected  to  be  quite  feasible  involving  two  or  three  man/weeks 
Cr  effort. 

The  fourth  part  was  the  correctness  of  the  compiling  algorithm  and  we  have 
just  presented  a natural  high  level  goal  structure  for  achieving  the  result.  It  is  not 
thought  there  would  be  any  conceptual  difficulties  in  forging  this  plan  into  a 
completely  formal  proof  but  the  time  taken  to  do  it  must  be  considerably  more  than 
was  required  for  the  simple  half  of  the  interpreter  proof.  We  estimate  that  It 
would  be  at  the  very  least  six  man/weeks  of  effort  using  the  current  LCP  system. 
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Thus  with  upwards  of  eight  man/weeks  of  effort  required  it  is  appropriate 
to  suspend  this  problem  until  a more  automatic  LCF  is  available. 


I 
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CHAPTER  11 

Second  generation  LCF  System 


Since  we  assert  that  LCF  is  a useful  (even  important)  tool  for  the  theory  of 
computation,  a major  aim  in  these  LISP  experiments  has  been  to  push  the  current 
system  io  its  limits.  In  many  directions  the  limitations  severely  handicap  the  user’s 
ability  to  specify  a proof  at  a natural  level  and  in  a compact  way.  We  present, 
therefore,  in  this  chapter  many  suggestions  for  improvements  to  the  system.  These 
improvements  will  probably  be  realised  in  a second  generation  system.  It  must  be 
acknowledged  that  several  of  the  ideas  were  developed  in  conjunction  with  Richard 
Weyhrauch  and  Robin  Milner. 


11.1.  Prior  Accomplishments 


Although  the  notion  of  conditional  simplification  arose  out  of  earlier  work  on 
LCF  by  Weyhrauch,  Milner  and  Newey,  it  was  implemented  for  this  work.  Without 
that  facility  the  proofs  would  have  been  much  longer. 

The  !PRLF  tactic’  mentioned  in  Chapter  3 was  implemented  after  the  bulk  of 
the  Pure  LISP  proofs  were  done  we  credit  the  current  work  for  its  development. 
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11.2.  Proof  Generation  vs.  Proof  Checking 

The  LCF  system  was  conceived  as  a proof  checker  which  had  some  ability 
to  help  the  user  generate  proofs  but  the  implementation  has  undergone  various 
mutations  which  were  all  intended  to  make  the  task  of  generating  easier.  Although 
it  still  claims  to  be  able  to  check  proofs,  the  considerable  complexity  of  the  more 
advanced  derived  deduction  rules  inevitably  diminish  confidence  in  the  checking 
process.  In  fact,  the  notions  of  checking  and  generating  are  confused  in  the  system 
design  and  inextricably  entwined  in  the  actual  code.  For  example,  if  the  user  calls 
for  a substitution  then  LCF  generates  an  appropriate  step  but  the  only  sense  in 
which  anything  is  checked  is  that  the  system  checks  that  the  user’s  prescriptions  do 
indeed  generate  a step. 

Simplification  is  particularly  worrisome  in  this  regard.  It  is  a very  complex 
deduction  rule  and  can  change  steps  so  drastically  that  the  user  is  simply  forced  to 
believe  that  the  machine  did  it  all  correctly  as  long  as  the  answer  'looks  good’. 

What  is  suggested  is  that  the  tasks  of  generation  and  checking  be  realised 
in  completely  separate  programs.  We  propose  a program  which  will  just  check 
proofs  where  steps  are  given  in  full  in  a restricted  version  of  the  logic  and  an 
interactive  program  which  will  translate  the  users  high  level  notions  into  a proof 
that  the  base  checker  (the  first  program)  can  validate. 
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It  will  be  most  important  for  the  base  checker  to  be  simple  because  we  will 
wish  to  have  confidence  in  it.  As  soon  as  practicable  we  would  want  it  proved 
correct.  Of  course,  it  would  be  nice  if  the  interactive  program  were  correct  too,  but 
that  concern  is  secondary  to  its  power  to  produce  proofs  with  a minimum  of  effort 
from  the  user.  Since  the  integrity  of  the  generator  is  not  of  great  importance,  the 
user  should  be  permitted  to  supply  actual  code  which  can  help  the  system  find  a 
proof. 

It  is  clear  that  we  expect  the  proof  generator  of  the  new  LCF  system 
(LCF2)  to  grow  up  to  be  an  interactive  theorem  prover  for  LCF,  so  more  emphasis 
will  be  placed  on  partial  decision  procedures  and  automatic  selection  of  deduction 
rules. 


1 1.3.  High  Level  Command  Language 

Using  the  current  system  is  rather  reminiscent  of  using  assembly  language; 
the  deduction  rules  correspond  to  the  instructions  in  that  when  each  command  is 
typed  in,  one  deduction  rule  is  applied.  It  is  clear  that,  in  LCF2,  the  input  language 
for  the  base  checker  wili  persist  in  being  low  level  but  the  language  with  which  we 
talk  to  the  interactive  proof  generator  should  have  various  features  of  high  level 
programming  languages. 
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1 1.3,1.  Data  iypes  and  Expressions 

We  propose  that  there  be  at  least  four  types  - term,  wff,  step  and 
simpset.  It  should  be  possible  to  have  variables  of  each  of  these  types  as  well  as 
constants.  The  'LABEL’  facility  of  the  current  system  is  actually  a simple  use  of 
variables  which  have  values  which  are  steps.  Of  course,  for  convenience  of 
programming,  integers  should  be  another  data  type  provided. 

There  will  be  many  operations  on  data  of  the  different  types,  including 
operators  which  correspond  to  many  of  the  deduction  rules  of  the  current  system. 
For  example,  'abstraction’,  'application’,  'symmetry’,  'transitivity’,  'fixed-point’, 
'substitution’  are  operators  which  transform  one  (or  more)  items  of  data  into  a step. 

The  notions  of  expression  and  assignment  follow  naturally  from  these  ideas 
of  data  types,  variables,  constants  and  operators. 

1 1.3.2.  Control  Structures 

It  is  a trivial  consequence  of  our  analogy  between  LCF  command  language 
and  conventional  programming  language  that  we  should  incorporate  control 
structures  such  as  procedures,  functions,  conditional  statements,  iterative 
statements,  compound  statements  and  blocks.  The  application  of  procedures  in  proof 
generation  is  in  the  binding  together  as  a body  many  commands  that  can  be  then 
thought  of  as  constituting  a recipe  for  producing  proof  for  some  step.  The  formal 
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parameters  of  procedures  and  functions  may  be  of  any  data  type  or  possibly 
functions  over  them.  Similarly,  an  iterative  statement  would  allow  some  command 
(or  sequence  of  commands)  to  be  repeatedly  executed  until  9ome  appropriate 
condition  is  satisfied.  Blocks  are  useful  for  delimiting  scope  of  variables. 


11.4.  Revised  Axiom  Structure 


In  the  current  system  one  can  only  present  nonlogical  axioms  to  the  machine 
if  they  have  the  form  of  WFFs.  Hence,  for  example,  one  is  prevented  from  having 
such  notions  as  Vx.  F(x)sA  H A^B  as  an  axiom  (in  that  form,  at  least).  This  is 
opposed  to  the  logical  axioms  of  LCF  (which  are  built  into  the  system)  such  as 
s1es2  H t(sl)Et(s2)  and  to  theorems  which  are  allowed  to  take  the  form  of  a 
sentence.  This  fact  has  led  many  users  to  adopt  the  rather  unfortunate  practice  of 
expressing  axiomatic  material  as  unproved  theorems  (in  fact  unprovable  theorems). 

It  would  appear  that  the  only  reason  that  axioms  are  not  allowed  to  be 
sentences  is  that  they  are,  unlike  theorems,  made  numbered  steps  in  the  proof.  As 
such  they  have  a WFF  part  and  a dependency  part  which  must  be  a list  of 
assumptions.  It  is  proposed  that  axioms  be  made  to  behave  more  like  theorems  than 
regular  steps  and  some  of  the  differences  between  theorems  and  steps  reduced.  In 
particular,  whenever  a step  expression  can  appear  as  an  argument  to  a rule,  an 
axiom  or  theorem  should  be  permissible. 


HiiVifirriafu  itHittlB 


W»-firmwr"Tfi  r'i»'-vn  <» t.'Hfaw.u -„w,;r„ 


ww&w&i'VGfe- 


1.5.  Extending  the  Pure  Lo<nc 


The  two  ways  of  expressing  implication  in  LCF  are  really  rather  restrictive. 


The  split  arrow  (*)  abbreviation  allows  relativisation  of  equations  by  truth-valued 


terms  only.  Also  the  turnstile  ( f-  ),  as  used  in  theorems,  can  only  appear  once  in  a 


theorem.  It  was  argued  in  the  last  section  that  this  turnstile  facility,  which  is  also 


used  to  express  the  logical  axioms  of  LCF,  should  be  made  available  for  axiom 


writing.  However,  perhaps  a more  general  attack  on  these  expressive  weaknesses 


of  the  current  logic  would  be  more  rewarding. 


There  have  been  occasional  instances  where  it  has  proven  quite 


inconvenient  to  have  just  the  rather  simple  formula  structure  we  have.  A good 


example  is  course-of-values  induction  over  the  natural  numbers,  which  can  best  be 


written  for  the  current  system  as: 


Vy.  [^H.  [xw.  Z(w)  -*  T, 

g(pred(w))  -*  H(pred(w)),l]](y)*  g<y)-T  . 


Now  if  we  extended  our  weak  notions  of  implication  and  universal 


abstraction  we  could  write 


e(0>  T,  Vy.  (Vx.  y>x-T  =>  g(x)uj)  d g(y)=T  ) 
h Vy.  g{y)aj 


Inspired  by  such  instances  as  we  have  in  figures  10.4  to  10.6,  we  note  that 
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in  normal  situations  we  can  have  wffs  with  identical  sequences  of  prefixes 
containing  cumbersome  relativisations.  When  we  conjoin  such  wffs  we  would  like  to 
only  write  the  prefix  sequence  once.  For  example,  we  would  much  rather  write  the 
goal  Vx.  A=>(B|,B2)  instead  of  the  goal  (Vx.  A*  B,),(Vx.  A*  B2)  . 

The  proposal  of  this  section  is  to  have  a syntax  for  Well-Formed  Formulae 
which  goes  like: 


<WFF>  ::=  <equivalence>  | <inequivalence> 

| V<varlist>  . <WFF> 
j <WFF>  =>  <WFF> 

| <WFF>  , <WFF>  . 


This  proposal  has  the  nasty  effect  that  the  induction  rule  of  LCF  has  to 
restricted  in  scope.  There  would  have  to  be  some  syntactic  check  made  on  wffs  to 
determine  whether  they  admit  induction.  Igarashi  has  studied  this  problem  in  [11]. 


1 1.5.1.  Derived  Deduction  Rules 

With  a high  level  command  language  as  we  proposed  and  with  the  richer 
implicati/e  structure  that  we  are  now  discussing,  one  is  able  to  write  in  the  logic, 
rules  of  the  form  below  which  would  have  to  be  built  into  the  system: 

A h B C H D 
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1 1.6.  Concrete  Syntax 


The  question  of  how  LCF  should  deal  with  syntax  of  programming  languages 
is  rather  important  since  we  hope  to  apply  the  system  to  many  languages.  The 
problem  is  that  we  want  to  be  able  to  specify  the  concrete  syntax  of  a language  so 
we  c n simply  refer  to  a program  by  its  text  and  have  the  system  deduce  its 
structure.  We  don  t have  a solid  solution  to  the  problem;  in  this  thesis  we  have 
discussed  some  questions  of  denotation  and  syntax  in  relation  to  LISP  and  LAP  but 
much  more  work  is  needed. 


11.7.  Extending  Simplification 


1 1.7.1.  Inequalities 

In  chapter  8 we  were  unable  to  complete  a proof  because  simplification, 
which  is  the  workhorse  of  the  system,  only  deals  with  equalities.  It  is  a little  more 
arkward  to  handle  inequalities  but  the  extent  of  the  technical  problems  is  the  fact 
that  applicability  depends  on  which  side  of  an  AWFF  is  being  simplified  and  whether 
the  user  is  doing  forward  or  backward  reasoning.  For  example,  A e B can  be  used 
to  simplify  a step  g(B)  ?C  to  a step  g(A)  e C but  not  used  to  simplify  a goal 
F e H(A)  . An  important  consideration  is  that  one  would  like  to  simplify  by 
equalities  before  inequalities  which  leads  us  to: 
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1 1.7.2.  Split  Level  Simplification 

There  are  many  reasons  why  users  want  some  simplification  rules  tried 
before  others.  The  most  notable  is  recursive  function  definitions  which  should 
usually  be  considered  last-resort  rules.  One  approach  which  at  least  deserves  trial- 
by-experience  is  the  idea  of  having  two  or  more  levels  of  simpset.  The  highest 
level  will  contain  rules  which  have  complicated  conditions  to  check  before  they  may 
be  applied  or  which  may  lead  to  excessive  expansion  of  the  formula  if  applied 
several  times  without  lower  level  rules  intervening 

1 1.7.3.  n-time  Simplification 

Another  facility  which  is  an  old  idea  (Weyhrauch)  is  that  of  having  a counter 
on  simplification  rules  which  enable  a user  to  specify  that  a certain  rule  (perhaps 
recursive)  should  only  be  used  a limited  number  of  times. 


1 1.7.4.  Subgoals  from  Conditional  Simplification 

When  simplification  is  used  as  a tactic  (i.e.  to  attack  a goal),  the  user  should 
be  able  to  nominate  certain  conditional  simplification  rules  which  are  always  applied 
when  the  left  hand  side  matches;  conditions  are  still  attacked  by  simplification  but 
those  that  are  not  reduced  to  trivialities  are  made  into  subgoals.  It  is  necessary  to 
specifically  nominate  rules  to  have  this  property  (globally  or  locally)  to  avoid 
generation  of  large  numbers  of  false  subgoals. 
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1 1.7.5.  Case  Analysis  in  Simplification 

Suppose  we  are  given  terms  A,  P and  G where  P and  G contain 
occurrences  of  A.  We  propose  that  simplification  should  normally  mutate  the  term 
A~F,G  through  A -♦  P-JT/AJ.G'JF/A}  to  perhaps  something  simpler,  (recall  that 
T{s/x}  denotes  the  result  of  substituting  s for  x in  T.) 

1 1.7.6.  Simplifying  Procedures 

In  the  current  system  members  of  the  simpset  have  the  form  C |-  A=B 
and  if  A matches  some  subterm  and  C is  satisfied  (by  recursive  call  on  simplification) 
then  B (appropriately  modified)  replaces  the  matched  subterm.  We  propose  a more 
general  scheme  where  items  in  the  simpset  are  triples  (A,C,F).  As  before  the  term 
A must  match  a subterm  before  any  consideration  is  given  to  the  item;  following  a 
match,  condition  C is  checked  (by  some  procedure)  and  if  it  is  OK  then  function  F 
(given  in  some  language)  is  executed  with  the  matched  subterm  as  a parameter. 


1 1.8.  Types 

In  his  original  suggestion  and  formulation  of  the  pure  logic  in  [1],  Scott 
chose  a typed  version  since  he  despaired  of  finding  a model  for  the  \-calculus  and 
concluded,  on  this  basis,  that  'the  theory  of  types  is  here  to  stay’.  Since  that  time, 
Scott  has  produced  models  for  the  \-calculus  in  [8],  has  repudiated  the  'OWHY 


paper  and  has  formulated  a type-free  logic  ([9]).  This  development  inevitably 
raises  the  question  as  to  whether  a new  LCF  system  should  be  typed  or  not. 

Now,  if  we  make  the  new  LCF  typed,  we  can  apply  some  lessons  learnt 
from  the  old  system.  Foremost,  the  system  should  be  made  to  check  types  of  terms. 
More  precisely,  the  system  should  check  that  a proof  is  consistently  typable;  the 
user  should  rarely  have  to  actually  specify  the  types  explicitly.  The  fact  that  the 
old  system  did  not  do  this  can  be  justified  on  the  grounds  that  it  was  the  prototype 
but  this  argument  does  not  apply  now.  Next  lesson  is  that  the  pure  logic  should  be 
changed  to  allow  an  arbitrary  number  of  base  domains,  instead  of  just  Dmd  and  Dtr  . 
In  using  the  current  system,  where  Dtnd  must  be  partitioned  into  various  notional  data 
types  (such  as  integers  and  lists),  one’s  theorems  tend  to  be  cluttered  up  with 
rolati visations;  Also,  many  theorems  only  exist  because  the  data  domains  are  only 
notional.  Then,  if  we  have  many  base  types,  we  must  also  think  about  a richer  type 
structure:  namely,  if  a and  /?  are  types  then  «-*/?  (as  before),  (disjoint  union) 
and  n*/<  (cartesian  product)  should  be  too. 

If,  on  the  other  hand,  the  new  LCF  implements  Scott’s  type-free  logic,  one 
must  provide  syntactic  sugar  with  which  the  user  may  restrict  terms  to  certain 
subdomains  (by  means  of  hidden  retractions)  to  achieve  notional  data-tvpes.  It  must 
be  noted  that  the  provision  of  this  facility  corresponds  approximately,  In  difficulty, 
to  building  type-checking  into  a typed  system. 
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The  debate  continues  as  to  which  of  these  options  is  best.  It  cannot  be 
denied  that  the  type-free  logic  is  mathematically  more  elegant.  Also,  some  people 
say  that  one  can  more  easily  axiorr.atise  programming  languages  with  functional  data 
types  using  it.  On  the  other  hand,  some  people  say  that  the  objects  we  deal  with  in 
computation  are  really  well-typed  and  that  when  one  is  proving  properties  of 
computable  objects  one  should  be  forced  to  recognise  the  type  structure. 
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11.9.  Miscellaneous  Improvements 

1 1.9.1.  Solving  Equations 

We  found  it  convenient  in  doing  the  LISP  experiments  to  have  various 
theorems  available  with  the  flavor  of 

P F,q  - T f-  P ~ F,  q - T 

and 

P -*  T,i  - T f-  P a T . 

With  a couple  of  dozen  such  theorems  one  can  break  down  some  quite 
complex  equations  to  give  specific  truth-values  for  some  of  the  subterms  of  the 
original  equation.  For  example 

p -*  T,  (q  -*  1,  (r  -»  T,s))  = F 
may  be  solved  for  p,q,r,s  (in  this  case  each  is  F). 

This  process,  which  we  call  ’solving  equations’  is  clearly  one  one  which 
should  be  automated. 
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1 1.9.2.  Definitional  Facilities 

In  the  current  system,  if  one  wants  to  name  (with  identifier  n,  say)  some 
complicated  term  T that  is  used  often  in  the  proof  of  some  step  S but  does  not 
actually  appear  in  the  step,  then  one  can  either  make  the  WFF  n»T  an  axiom  or  an 
assumption.  In  one  case  one  gets  to  complicate  the  axioms  unecessarily  and  in  the 
other  case  n=T  becomes  a dependency  of  S.  This  deficiency  must  be  removed  in 
the  next  system. 

1 1.9.3.  Automatic  Forward  Reasoning 

We  propose  to  have  a set  of  sentences,  called  an  FR-set,  and  a mechanism 
called  'Consequences’.  When  Consequences  is  invoked  with  a set  of  steps, 
antecedents  of  sentences  in  the  FR-set  are  checked  for  satisfiability  by  the 
nominated  steps.  If  all  antecedents  of  a sentence  check  out,  then  the  consequent 
(with  appropriate  instantiation)  is  made  into  a new  step  in  the  proof  and  perhaps 
added  to  the  simpset.  It  should  be  clear  that  if  a step  so  generated  happens  to  be 
a standard  contradiction  then  the  current  goal  will  be  established. 

1 1.9.4.  More  Abbreviations 

The  universal  quantifier  and  relati visation  (split  arrow)  abbreviations  of  LCF 
have  been  very  successful.  It  seems  that  abbreviating  the  term  P ->  F,T  as 
would  also  be  extremely  useful. 
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We  propose  also  that  empirical  study  be  devoted  to  having  P a Q as  an 


abbreviation  for  one  of  the  terms  P -»  Q,F  and  P -»  Q,Q  -»  F,F  . Similarly,  P v Q 
could  be  a abbreviation  for  one  of  the  terms  P ->  T,Q  and  P -*  (Q  ->  T,T),Q  . 
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CHAPTER  12 
Conclusion 

This  thesis  has  been  an  extensive  exercise  in  the  application  of  LCF  to  the 
definition  of  some  programming  languages  - a subset  of  a machine-language  and 
some  subsets  of  LISP.  In  each  of  the  several  cases,  we  have  defined  the 
language  axiomatically  but  have  also  illustrated  how  a 'theory’  for  the  language 
should  be  constructed  using  the  axioms  as  a base.  The  theory  of  a language  then 
becomes  a framework  in  which  programs  of  the  language  can  be  proved  correct. 

[23]  classifies  methods  of  definition  of  semantics  as  being  either 
constructive’  and  suited  to  the  needs  of  the  implementor  or  'implicit5  and  suited  to 
the  needs  of  the  user.  It  then  argues  that  a language  should  be  defined  both  ways 
and  the  definitions  proved  consistent.  In  the  present  work,  the  definition  of  Pure 
LISP,  for  example,  is  clearly  constructive  but  many  of  the  theorems  of  the  Theory  of 
Pure  LISP  have  the  flavour  of  rules  in  Hoare’s  method  ([20]).  It  would  be 
interesting  to  investigate  whether  some  subset  of  theorems  of  the  Theory  of  Pure 
LISP  could  be  used  as  a satisfactory  implicit  definition. 

We  note  that  the  recent  independent  work  of  M.  Gordon  [16]  also  gives  a 
semantics  of  Pure  LISP  leading  to  a proof  of  correctness  of  'eval’  etc.  We  observe 
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several  significant  differences  of  approach  which  make  his  work  and  this  thesis 
somewhat  complementary.  Gordon  ascribes  denotations  directly  to  Pure  LISP 
M-expressions  using  Scott/Strachey  style  semantic  equations  (as  in  [29])  whereas 
we  have  it  that  S-expressions  denote  functions  under  interpretation  of  a particular 
'eval’  function  written  in  t.CF.  Gordon’s  approach  makes  use  of  much  more  logical 
machinery  than  is  available  in  LCF  and  so  his  proofs  are  not  checkable  mechanically 
(as  yet).  Machine  checkability  was  a prime  requirement  in  this  thesis  since 
automation  is  the  ultimate  goal  of  the  project. 

The  way  we  were  able  to  separate  syntax  from  semantics  by  means  of 
notation  and  denotation  considerations  is  a technique  that  hopefully  could  be  applied 
with  benefit  to  other  languages;  certainly,  it  solved  the  problem  completely  in  the 
cases  we  studied. 

As  an  experiment  in  the  application  of  LCF  to  the  specification  of 
programming  language  semantics,  the  work  was  very  encouraging.  The  logic  has 
distinguished  itself  as  regards  expressive  power;  the  actual  definitions  of  the 
various  languages  are  concise  and  elegant.  It  is  true  that  in  the  case  of  Pure  LISP 
the  language  being  defined  and  the  formalism  are  similar  in  structure  but  LAP  is 
certainly  different  in  structure  to  LCF  and  current  work  on  an  axiomatisation  of 
PASCAL  by  Aiello  et  al  ([10])  is  proceeding  well. 

It  is  worth  noting  that  we  were  able,  in  the  case  of  LAP,  to  give  a partial 
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specification  of  a language  and  also,  as  in  the  case  of  Pure  LISP,  give  a complete 
description  of  a language. 

Alihough  LCF  is  yet  in  its  infancy  of  development,  it  has  already  proved 
very  suitable  for  discussion  of  Pure  LISP  programs.  We  would  like  to  claim  this  is 
some  evidence  that  LCF  has  a bright  future  in  the  area  of  program  correctness. 
There  are  many  aspects  of  the  LCF  system  which  have  helped  substantially  in  proof 
generation  but  the  proofs  cry  out  for  more  mechanisation  and  more  powerful 
deduction  rules. 

We  claim  that  this  point  in  ‘ime  is  the  end  of  the  first  cyle  of  development 
for  LCF.  Clearly  the  time  is  ripe  fo*  developing  a brand  new  LCF  system  which 
incorporates  the  suggestions  we  have  presented.  Effort  spent  in  this  direction 
should  generate  the  most  payoff.  After  that  is  done,  a revamping  of  the  work  on 
integers,  lists  and  finite  sets  would  be  profitable  since  the  axiomatisations  could  be 
polished  somewhat.  Also  it  would  give  a good  measure  of  the  improvement  in 
deductive  power  between  the  two  generations. 

Redoing  the  Pure  LISP  proofs  and  completing  the  proof  of  correctness  of 
the  Pure  LISP  interpreter  on  the  machine  is  a must  and  another  look  at  the 
correctness  of  LComO  would  be  appropriate.  An  option  to  be  kept  in  mind  at  that 
time  would  be  the  reduction  of  the  subset  of  LISP  that  LComO  is  written  in  and 
compiles.  The  AND,  OR,  and  NOT  features  could  be  removed  and  that  would  simplify 
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the  compiler  substantially  but  not  to  the  point  of  no  interest.  However  if  the 

f ... 

increase  in  power  in  new  LCF  lives  up  to  hopes,  this  will  not  be  necessary.  In  fact 

I.  ! 

we  would  expect  to  be  able  to  attack  the  LCom4  compiler  mentioned  in  [13], 
although  our  present  treatment  cf  LAP  would  then  be  inadequate. 

The  compiler  proof  has  a number  of  disadvantages  as  an  experiment  using 
LCF.  Most  important  of  these  is  that  it  encourages  work  on  a rather  artificial  subset 
of  LISP  and  gross  simplifications  of  PDP10  code.  It  would  seem  more  fruitful  to  pick 
an  experiment  which  would  encourage,  instead,  more  sophisticated  theories  of  a low 
level  language  or  a high  level  language. 
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APPENDIX  1 

Theorems  of  LComO  LISP 


In  this  appendix  we  report  on  the  Theory  of  LComO  LISP  that  was 
developed  as  background  for  the  compiler  proof.  The  axioms  on  which  this  collection 
of  theorems  is  based  are  given  in  the  first  2 sections  of  Chapter  9.  Note  that 
practically  all  the  results  are  suitable  for  direct  inclusion  in  a SIMPSET. 

The  Interpreting  Functions: 


In  this  section  we  present  theorems  to  do  with  the  LCF  functions  of  the 

interpretive  semantics  for  LComO  LISP  - namely,  'evaP,  'evcon’,  'evand’,  'evor’, 

'apply',  'evlis’  and  'pairlis’  (in  that  order); 

h Vx  y.  eval(l,x  y)  s j. 
h Vx  y.  eval(x,i,y)  = l 
h Vx  y.  eval(x,y,l)  » l 
o(eval(x,v,f))  s|  (.  ti(x)  a T 
ci(eval(x,v,f))  s | f.  a(v)  s j 
<:i(eval(x,v,f))  = J (i  n(f)  3 J 
h Vv  f.  eval(NIL,v,f)  a ^(v)-*(ci(f)-*NIL,i),i 
isint(x)  s 7 f.  Vv  f . eval(x,v,f)  3 ii(v)-*(ci(f)-*x,l),i 
isname(x)  3 7(  islist(vb)  3 7,  c'(FL)  3 7 

h Vy.  eval(x,(x*y)*vb,fl)  3 y 
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ioname(x):-T,  c«(y  1 >-T,  x-xl^F,  islist(vb>=T,  4(fl)=T 

h Vy.  eval(x,(xl«yl)»((x=y)«vb),fl)  a y 
isname<x)~T,  d(yl>^T,  c'(y2HT,  x=xl=F, 
x-x2-F,  isliot(vb)--T,  £'(fl>~T 

}-  Vy.  eval(x,(xl«yl).((x2«y2)-((x7)-vb)),fl)  = y 
H(vb)  T,,;i(fl)-  T }-  Vx  . eval(0UOTE‘(x-'NIL),vb,fl)  = x 
|-  Vx  vb  fl.  eval(COND*x,vb,fl)  a evcon(x,vb,fl) 
h Vx  vb  fl.  eval(AND’X,vb,fl)  a afvbWMflHevandfx.vb.fl),!),! 
b Vx  vb  fl.  eval(OR»x,vb,fl)  3 a( vb)-»(d(fl)^evor(x,vb,fl),±),x 


b Vx  y.  evcon(l,x,y)  3 1 
|-  Vx  y.  evcon(x,l,y)  3 1 
b Vx  y.  evcon(x,y,i)  n 1 
H Vvb  fl.  evcon(l\IIL,vb,fl)  2 1 

H Vx  y vb  fl.  evcon(((QUOTE«(T'NIL)Hx^lL))«y,vb,fl)  2 afyJ-^evaKx.vb.fl)  1 
b Vx  y w vb  fl.  evcon((w(x*NIL))*y,vb,fl)  3 i(xHa(y)-> 
(null(eval(wlvbIfl))-*evcon(ylvb,fl)Ieval(x,vb,fl)),i)1i 


\-  Vx  y.  evand(l,x,y)  h 1 
b Vvb  fl.  evandfNIL.vb.fl)  s T 
1-  Vx  y vb  fl.  evand(x7,vb,fl) 

= a(y)-*(null(eval(xlvblfl»-*NIL,evand(yivb,fl))1l 

H Vx  y.  evor(i,x,y)  2 j. 

H Vvb  fl.  evorfNIL.vb.fl)  a NIL 
H Vx  y vb  fl.  evor(x»y,vb,fl) 

s a(y)-‘(null(eval(x,vb,fl))-*evor(y,vb,fl),T),l 


|-  Vx  vb  fl.  apply(l,x,vb,fl)  3 1 
b Vfn  vb  fl.  apply(fn,l,vb,fl)  = 1 
|-  Vfn  x fl.  applyffn.x.l.fl)  a l 
b Vfn  x vb.  cipply(fn,x,vb,i)  s 1 
.:i(apply(fn,x,vb,fl))  ~Tb  a(fn)  0 T 
c*( applyf fnjX.vb.fl))  : J b a(x)  3 j 
.:<(apply(fn,x,vb,fl))  2 j j.  ,;i(vb)  = T 
C<( applyf fn,x,vb,fl)>  - T (■  a(f|)  = j 
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h Vvb  fl.  evlis(l.vb.fl)  3 j. 

Giist(x)  = ii-  }-  Vvb  fl.  evlisfx.vb.fi)  3 j. 


Vvb  fl.  evlis(NIL, vb.fi)  3 NIL 
Vx  vb  fl.  evlis(x’NlL,vb,fl)  3 eval(x,vb,fl)«NIL 
Vxl  x2  vb  fl.  evlis(xHx2’NIL),vb,fl) 

- eval(xl,vb,f!)*(eval(x2,vb,fl)»NIL) 

Vxl  x2  x3  vb  fl.  evlis(xHx2*(x3«NIL)),vb,fl) 

3 eval(xl,vb,fl)*(eval(x2,vb,fl)«(eval(x3,vb,fl)«NIL)) 


h 

H 

h 

h 

h 


Vx  a.  pairlisd.x.a)  - 1 
Vx  y.  pairlis(x.y.l)  3 i 
Vx  a.  pairlfs(NIL,x,a)  3 a 
Vx  y a.  pairlis(x’NIL.y'NIL.a)  = (x»y)°a 
Vxl  x2  yl  y2  a.  pairlis(xMx2’ML),yHy2'NIL),a) 
n <xl »y  1 )»((x2*y2)*a) 

Vxl  x2  x3  yl  y2  y3  a . pairlis(xl»(x2»(x3»NIL)),yl-(y2»(y3»NIL)),a) 
3 <x  1 »y  1 )»((x2*y2)»((x3»y3)*a)) 


The  Built-In  Functions! 


Presented  here  are  the  effects  of  applying  'eval’  to  expressions  of  the 
form  F X (where  F is  a built-in  function)  and  applying  'apply’  to  built  in  functions 
and  suitable  argument  lists. 


\-  Vx  vb  fl.  apply(CAR.X’NIL,vb.fl)  = 0(vbMa(fl)^hd(x),J.),l 
h Vx  vb  fl.  apply<CDRlx»NIL,vb,fI)  3 a(vbMa(flMI(x),±),i 

Vx  vb  fl.  apply(NOT,x»NIL,vb,fl)  3 a(vbMa(flMnull(x)-+T,NIL),i),i 
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Vx  vb  fl, 
Vx  y vb 
Vx  vb  fl, 
Vx  y vb 
Vx  y vb 
Vx  y vb 
Vx  vb  fl, 
Vx  vb  fl. 
Vx  vb  fl, 
Vx  y vb 


apply(ATOM,X‘NIL,vb,fl)  = a(vbMa(flMatom(xHT,NIL),l),l 
fl.  apply(CONSfx«(y«'NIL)lvb,fl)  3 a(vbHa(flHx’y),l),l 
apply(LIST,x,vb,fl)  = a(  vbJ-^OffD-^x.iJ.X 
fl.  apply(EQUAL,x»(y»NIL),vb,fl)  = a(vbMa(flM(x=yHT,ML),l),± 
fl.  apply(PLUS,X'(yNIL))vb,fl)  3 a(vbMa(fl)->(x+y),l),l 
fl.  apply(TIMES,x»(y'NIL),vb,fl)  3 a(vbMa(fl)-*(x*y),l),l 
apply(MINUS,x-NIL,vb,fl)  3 a(vbMa(fl)-»mns(x),l),l 
apply(GENSYM,x«NIL,vb,fl)  3 a(vbMa(fl)-*gensym(x),l),l 
apply(NUMBERP,x«NIL,vb,fl)  3 a(vb)-»(a(fl)->(i8int(x)-»T,NIL),l),l 
fl.  apply(GREATERP,x»(y«NIL),vb,fl) 

3 a(vb)-»(J(fl)-»((x>y)-»T,NIL),i),i 


Vx  vb  fl. 
Vx  vb  fl. 
Vx  vb  fl. 
Vx  vb  fl. 
Vx  y vb 
Vx  vb  fl. 
Vx  y vb 


H Vx  y vb 


H Vx  y vb 


[-  Vx  vb  fl, 
H Vx  vb  fl, 
H Vx  vb  fl, 
h Vx  y vb 


eval(CAR"(x°NIL),vb,fl)  3 hd(eval(x,vb,fl)) 
eval(CDR''(x»NIL)lvb,fl)  3 tl( eval(x,vb,fl>) 
evel(NOT^(x-NIL),vb,fl)  3 null(x)-»T,NIL 
eva!(ATOM(X'NIL),vb,fl)  3 atom(eval(x,vb,fl))->T,NIL 
fl.  evai(CONSf(X''(y'NIL)),vb,fl)  3 eval(x,vb,fl)»eval(y,vb,fl) 
eval(LIST'X,vb,fl)  3 evlis(x,vb,fl) 
fl.  eval(EQUAWx«(y*NIL)),vb,fl) 

3 (eval(x,vb,fl)=eval{y,vb,fl))-»T,NIL 
fl.  eval(PLUS-(x’(y'NIL)),vb,fl) 

3 eval(x,vb,fl)+evaHy,vb,fl) 
fl.  eval(TIMESKxKy»NIL)),vb,fl) 

3 fival(x,vb,fl)*eval(y,vb,fl) 
eval(MINUS<(x'NIL),vb,fl)  3 mn$(eval(x,vb,fl)) 
eval(GENSYM'(x'NIL),vb,fl)  3 ger,5ym(eval(x,vb,fl)) 
eval(NUMBERP»(x-NIL),vb,fl)  3 isint(eval(x,vb,fl))-»T,NIL 
fl.  eval(GREATERP'(x-(yNIL)),vb,fl) 

3(eval(x,vb,fl)>eval(y,vb,fl))  -*  T,  NIL 


LAMBDA  Expressions: 


Here  we  give  the  effect  of  'eval’ing  and  'applying  LAMBDA  expressions. 


H Vb  vb  fl.  apply((LAMBDA  NIL  b),NIL,vb,fl)  3 eval(b,vb,fl) 
H Vx  y b vb  fl.  apply((LAMBDA  (x)  b),(y),vb,fl) 

3 eval(b,(X'y)’vb,fl) 
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}•  Vxl  x2  yl  y2  b vb  fl.  apply(  (LAMBDA  (xl  x2)  b;,(yl  y2),vbfl) 

- eval(b,(xl«ylH(x2"y2)’vb),fl)  ’ * Y '’  ,W 

h Vxl  x2  x3  yl  y2  y3  b vb  fl.  apply(  (LAMBDA  (xl  x2  x3)  b) 

.(yl  y2  y3),vb,fl) 

s eval(b,(xl»ylH(x2«y2H(x373)«vb)))fl) 

}-  Vb  vb  fl.  eval((LAMBDA  NIL  b>NIL,vb,fl)  a evaKb.vb.fl) 

H Vx  y b vb  fl.  e\  .(LAMBDA  (x)  b)-(y),vb,fl) 

= evalfb,  (x»eval(y,vb,fl))»vb,  fl) 

r Vxl  x2  y]  y2  b vb  (I-  evaK(LAMBDA  (xl  x2)  b>(yl  y2)vbfl) 

h vx,  x2  x3  yrf2bv3btrflyl,vb'f,)H(x2-evai(y2'vb’,i,)^b);f,) 

eval((LAMBDA  (xl  x2  x3)  b>(yl  y2  y3).vbfl) 

- evaKb,  (x  1 -eval(y  1 ,vb,fl))K(x2-eval(y2,vb,fl)) 

»{{x3*eval(y3,vb,fl))-vb)),  fl) 


I 


The  Basic  Functions: 


Here  we  give  the  meanings  (under  interpretation)  of  the  basic  LISP 
functions  defined  in  Fig.  5.4: 


BFD(FL)  s|  |i  assoc(NULL,FL)  = Snull, 

assoc(DIFFERENCE,FL>  a SdiFFerence, 
assoc(ISLIST,FL)  s Sislist, 
assoc(ASSOC,FL)  = Sassoc, 
assoc(LENGTH,FL)  a Slength, 
assoc(APPEND,FL)  a Sappend 

BFD(FL)  = T H islist(FL)  = T 

BFD(FL)  =T  b Ve  vb.  apply(NULL,e'NIL,vb,FL) 

3 islist(vb)  *(null(e)-»T,NIL),l 
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BFD(FL)  = T I-  Ve  vb.  eva!(NULL»(e»NIL),vb,FL) 

» nu!l(eval(e,vb)FL))-»T.NIL 

BFD(FL)  h T |-  Vx  y vb.  apply(DIFFERENCE,x»(y»l\IIL),vb,FL) 
® islist(vb)-*(x-y),i 

BFD(FL)  S3  T H Vx  y vb.  eval(DIFFERENCE«(x.(y.NIL)),vb,FL> 
3 evaKx.vb.FD-evaKy.vb.FL) 

BFD(FL)  3 J | - Ve  vb.  apply(ISLISl>NIL,vb,FL) 

3 islist(vb)-‘(islist(e)^T,NIL),l 
BFD(FL)  - T \ - Ve  vb.  eval(ISLIST-<e*N!L),vb,FL) 
ss  islist(eval(e,vb,FL))-*T,NIL 

BFD(FL)  u T 1-  Vx  y vb.  apply(ASSOC,x*(yNIL)lvblFL) 

= islist(vb)-*asGoc(x,y),i 

BFD(FL)  3 T H Vx  y vb.  eval(ASSOC*{x*{yMIL)),vblFL) 

= assoc(eval(x)vb,FL)leval(ylvb,FL)) 

BFD(FL)  3 I (.  Ve  vb.  appiy( LENGTH, e^NlL.vb.FL) 

3 islist(vbHength(e},l 

BFD(FL)  3 j |-  Ve  vb.  eval(LENGTH'(e^NIL),vb,FL) 
s length(eval(e,vb,FL)) 

BFD(FL)  3 x |-  Vx  y vb.  apply( APPEND, x«(y»NIL),vb,FL) 
s islist(vb)-»(x&y),l 

BFD(FL)  3 T |-  Vx  y vb.  eval(APPEND«(x*(y»NIL)),vb,FL> 
s evaKx.vb.FDAevaKy.vb.FL) 
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r APPENDIX  2 

Yet  Another  LISP  Subset 

*9' 

O' 

In  Figure  A2.1  (next  three  pages)  we  give  an  interpretive  semantics  for  yet 
another  subset  of  LISP  - a superset  of  Pure  LISP  which  has  SETs,  SETQs, 
PROGs,  GENSYMs  and  property  lists  as  well  as  the  AND,  OR,  NOT  and 
LIST  operations  introduced  in  LComO  LISP.  This  semantics  includes  all  the 
techniques  that  we  discussed  while  developing  the  other  versions  of  LISP. 

The  'eval’  and  'apply’  functions  in  the  definition  of  Pure  LISP  had  a 
parameter  which  was  an  A-list  for  holding  the  values  of  bound  variables.  The 
corresponding  functions  in  this  treatment  have  a 'state’  parameter  instead;  A state  is 
a triple  of  A-list  (for  bound  variable  values),  list  of  property  lists  of  variables  and 
memory  for  the  gensym  function,  To  allow  for  side-effects,  each  of  the  functions 
( eval , apply , etc.)  returns  as  a pair,  the  regular  answer  and  a new  state. 


* I 
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♦♦AXIOM  NL1: 

lisp  - [xe.  hd(eval{e,NIL*(NIL'G0001)))] 


eval  - [mB.  evalFfB)], 
evalF  ~ [xB  x st.  c<( st)  -* 

null(x)  -»  NIL'st, 
isint(x)  x«st, 

isname(x)-»[xy.  null(y)-*tl(assoc<VALUE,tl<assoc<x,tl<hd<st))))))»st( 

tl{y)»st]  (ossoc(x,hd(hd(st)))), 

atom(x)  1, 

hd(x)=QUOTE  -*  hd(tl(x)Kt, 


hd(x)=COND 

hd(x)=AND 

hd(x)=OR 

hd(x)=PROG 


4 [MG.evconF(B,G)](tl(x),st), 

* [MG.evandF(B.G)]  (tl(x),st), 

^G.evorRB.G)]  (tl(x),st), 

■*  friG.evprog(B,G)] 

(tl(tl(x)),  initvars(hd(tl(x)),hd(st)),  tl(st)), 


hd(x)=GENSYM-*  [xz.  z • (hd(st)-(hd(tl(st))-z))] 

(gensym(tl(tl(st)))), 


hd(x)=SETQ 


► [xvst. 

[xvar  val  stl. 

[xal  pi  gm. 

[xy.  null(y)  -♦ 

val'(al*(put(  val, var, VALUE, pl)*gm)), 
vaN  set  ( var,val,al) »( pPgm) ) ] 
(assoc(var.al))] 

<hd(st  l),hd(tl(stl)),tl(tl(st  1)))] 
(hd(tl(x)),hd(vst),tl(vst))] 

(B(hd(tl(tl(x))),st)), 


[xz.  [/iG.applyF(B,G)](hd(x),hd(z),tl(z))] 
<[MG.evlisF<B,G>](tl(x),st)),JL], 


Figure  A2.1a  - Axioms  for  Yet  Another  LISP. 
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evcon  s [/iG.  evconF(eval,G)], 
evconF  3 [xF  G x st.  [xz.  null(hd<z))-*F< il<x),tl(z)), 
G{hd(tl((hd(x))),tl(z))](F(hd(hd(x)),st))], 


evand  3 [^Q,  evandF{eval,G)], 

evandF  a [xF  G x st.  null(x)-*T,  [xz.  null(hd(z))-»NIL,G(tl(x),tl(z))] 

(F(hd(x),st))], 

evor  s [/iG.  evorF(eval,G)], 

evorF  = fxF  G x st.  null(x)->NIL,  [xz.  null(hd(z))-*G(tl(x),tl(z»,T] 

(F(hd(x),st))], 

evlis  = [/iG.  evlisF(eval,G)], 
evlisF  3 [\F  G m vb  fl.  null(m)-»MIL«st, 

[xx.[xy.  (hd(x)'hd(y))  . tl(y>]  (G(tl(m),tl(x))] 

(F(hd(m),st))]], 

evprog  3 [^g.  evprogF(eval,G)], 

evprogF  = [xF  G m vb  fl.  null(m)-*NIL‘st,  [xx.  G(tl(m),tl(x)](F(hd(m),st))], 


apply  3 [nG.  applyFfeval.G)], 
applyF  3 [xF  G fn  x st.  c'i(x)  -♦  a(st)  -4 
(fn=LIST)  -*  x«st, 

(fn=SET)  -*  hd(tl(x))»set(hd(x),hd(tl(x)),st), 

(fn=GET)  - get(hd(x),hd(tl(x)),hd(tl(st))*st, 

(fn-PUT)  -*  hd<x)»(hd(st)» 

(put<hd(x),hd(tl(x)),hd(tl(tl(x))),hd(tl(st)))*tl(tl(st)))), 
isBF(fn)  -*  applyBF<fn,x)*st, 
isname(fn)  G(hd(F(x,st)),x,$t), 

(hd(fnHLAMBDA)-1  [xz.  hd(z)  • 

(prune(hd(tl(z)),hd(st)MI(tl(z)))] 
(F(hd(tl(tl(fn))),pairlis(hd(tl(fn)),x,hd(st))'tl(st))), 
(hd(fn)=LABEL)-*  [xz.  hd(z)«  (tl(hd(tl(z)MI(tl(z)))] 

(G(hd(tl(tl(fn))),  x, 

((hd(tl(fn))’hd(tl(tl(fn))))«hd(st))«tl(st))), 

1, 1,  1 ], 


Figure  A2.1b  - Axioms  for  Yet  Another  LISP  (ctd). 
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pairlis  - [#iG.[xx  y st.  null(x)  -»  (nu!l(y)  -♦  st,  1), 

[\2.  ((hd(x)*hd(y))*hd(z))  • tl<z)](G(tl(x),tl(y),st))]] 

prune  - [^iG.[xx  y.  Iength(x)=length(y)  ->  x,  G(tl(x),y)], 

set  " [mG.[xx  y a (hd(hd(a))=x)  - (x^yMKa),  hd(a)«G(x,y,tl(a))]], 

put  ='  [/iG.  [xvar  val  pn  pi. 

null(pl)  -»  (var"((pn"val)'NIL))*pl, 

(hd(hd(pl))=var)  -*  (var°set<pn,val,tl(hd(pl)))MI(pl), 
hd(pl)<>G(var,val,pn,tl(pl))]], 

initvars  b [/iG.fxvl  al.null(vl)  -4  al,(hd( vl).rsJIL)*G(tl(vl),al)]], 

get  = [nG.  [xvar  pn  pi.  null(pl)  ->  NIL, 

(hd(hd(pl))=var)  -+  [xz.  null{z)  -♦  NIL,tl(z)] 

<assoc(pn,tl(hd(pl)))), 

G(var,pn,tl(pl))]], 

isBF  3 [xx.  (x=CAR)-T,  (x=CONS)-*T,  (x=MINUS)-*T, 

(x-CDRHT,  (x=PLUSHT,  (x=GENSYM)-»T, 

(x=NOTHT,  (x=EQUAL)-+T,  (x=NUMBERP)->T, 

(x-ATOM)-T,  (x=TIMES)-»T,  (x=GREATERP)] 

applyBF(CAR)  3 [xx.  hd(hd(x))], 
applyBF(CDR)  3 [xx.  tl(hd(x))j, 
applyBF(NOT)  3 [xx.  null(hd(x)/-»TlNIL], 
applyBF(ATOM)  3 [xx.  atom(hd(x))-+T,NIL], 
applyBF(CONS)  -•  [xx.  hd(x)'hd(tl(x))], 
applyBF(PLUS)  [xx.  hd(x)+hd(tl(x))], 
applyBF(EQUAL)  3 [xx.  hd(x)=hd(tl(x)HT,NIL], 
applyBF(TIMES)  3 [xx.  hd(x)*hd(tl(x))], 
applyBF(MINUS)  =•  [xx.  mns(hd(x))j, 
applyBF(GENSYM)  « [xx.  gensym<hd(x))], 
applyBF(NUMBERP)  3 [xx.  isint(hd<x))->T,NIL], 
applyBF(GREATERP)  = [xx.  <hd(x)>hd<tl(x)))-»T,NIL] 
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Figure  A2.1c  - Axioms  for  Yet  Another  LISP  (ctd). 
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